Hey All, I got bitten by the current zope subversion setup at PyCon so thought I'd mail the appropriate groups about it. If this has been covered elsewhere and I've missed anything, please just point me in the right direction... So, svn.zope.org causes me pain at the moment: - it uses the bizarre svn or svn+ssh protocols, which I find annoying (ports blocked on routers, can't check with a browser, etc) - the web front end is ancient and not as good as other options (Trac, WebSVN) - the process for adding keys is baroque and managed by one person who is too busy to help with it (Jim) So I thought I'd ask what the plans are now that the foundation owns all the Zope IP (has this happened yet or am I imagining things?) Are we sticking with svn? Are we sticking with the current hosting? Are we sticking with the current key-based login and upload mechanism? For me, the ideal would be simply https for everything and using http basic auth for access with more people having access to update the passwd file and maybe Trac or WebSVN for a nice web interface. I volunteer to help with any/all of the above. The other option would be to follow Python and move to Mercurial, but that has the same problems for me as with Bzr (no decent gui tools, less mature, etc) although it's a toolset I'll have to learn at some point anyway... cheers, Chris -- Simplistix - Content Management, Zope & Python Consulting - http://www.simplistix.co.uk
On Thu, Apr 2, 2009 at 20:31, Chris Withers <chris@simplistix.co.uk> wrote:
For me, the ideal would be simply https for everything and using http basic auth for access with more people having access to update the passwd file and maybe Trac or WebSVN for a nice web interface.
I volunteer to help with any/all of the above.
My offer to set up Trac as a buildout still stands too. Jens, have your concerns about dependencies been answered? -- Martijn Pieters
Martijn Pieters schrieb:
On Thu, Apr 2, 2009 at 20:31, Chris Withers <chris@simplistix.co.uk> wrote:
For me, the ideal would be simply https for everything and using http basic auth for access with more people having access to update the passwd file and maybe Trac or WebSVN for a nice web interface.
I volunteer to help with any/all of the above.
My offer to set up Trac as a buildout still stands too.
Jens, have your concerns about dependencies been answered?
I also offer my help to install and maintain a trac and, if needed, the svn installation. ..Carsten
On Apr 2, 2009, at 2:31 PM, Chris Withers wrote:
For me, the ideal would be simply https for everything and using http basic auth for access with more people having access to update the passwd file and maybe Trac or WebSVN for a nice web interface.
I absolutely *hate* using https to access subversion. This involves storing a key in plane text in my home directory, which is terrible. I far prefer using ssh-based infrastructure for this sort of thing. Jim -- Jim Fulton Zope Corporation
On Thu, Apr 2, 2009 at 20:39, Jim Fulton <jim@zope.com> wrote:
On Apr 2, 2009, at 2:31 PM, Chris Withers wrote:
For me, the ideal would be simply https for everything and using http basic auth for access with more people having access to update the passwd file and maybe Trac or WebSVN for a nice web interface.
I absolutely *hate* using https to access subversion. This involves storing a key in plane text in my home directory, which is terrible. I far prefer using ssh-based infrastructure for this sort of thing.
This is no longer the case for subversion 1.6 and up, the password is now stored encrypted, and subversion now supports KWallet, GNOME Keyring, Mac OS Keychain, and Windows CryptoAPI for storage. See: http://subversion.tigris.org/svn_1.6_releasenotes.html#auth-related-improvem... -- Martijn Pieters
On Thu, 2009-04-02 at 20:43 +0200, Martijn Pieters wrote:
On Thu, Apr 2, 2009 at 20:39, Jim Fulton <jim@zope.com> wrote:
On Apr 2, 2009, at 2:31 PM, Chris Withers wrote:
For me, the ideal would be simply https for everything and using http basic auth for access with more people having access to update the passwd file and maybe Trac or WebSVN for a nice web interface.
I absolutely *hate* using https to access subversion. This involves storing a key in plane text in my home directory, which is terrible. I far prefer using ssh-based infrastructure for this sort of thing.
This is no longer the case for subversion 1.6 and up, the password is now stored encrypted, and subversion now supports KWallet, GNOME Keyring, Mac OS Keychain, and Windows CryptoAPI for storage.
See: http://subversion.tigris.org/svn_1.6_releasenotes.html#auth-related-improvem...
However, this only *allows* clients to manage their password reasonably, it doesn't force them to. SSH usually complains about bad permission settings on files etc and I guess is usually handled better. (Note: you can't force a passphrase onto the client either.) From my understanding, the interesting part is what the DVCSs do: let people sign their commits with e.g. their PGP key (strong auth) and allow them to share that data somewhere (different mechanism maybe not so strong auth). Christian -- Christian Theune · ct@gocept.com gocept gmbh & co. kg · forsterstraße 29 · 06112 halle (saale) · germany http://gocept.com · tel +49 345 1229889 7 · fax +49 345 1229889 1 Zope and Plone consulting and development
Christian Theune wrote:
See: http://subversion.tigris.org/svn_1.6_releasenotes.html#auth-related-improvem...
However, this only *allows* clients to manage their password reasonably, it doesn't force them to.
Well, you can't force someone to keep their private key private either... At the end of the day, if an svn account is compromised, we'll see a load of bogus commits. My understanding of svn is that those are moderately easy to remove.
From my understanding, the interesting part is what the DVCSs do: let people sign their commits with e.g. their PGP key (strong auth) and allow them to share that data somewhere (different mechanism maybe not so strong auth).
Well, the only "auth" bit seems to be where the "offical" changesets are.. Chris -- Simplistix - Content Management, Zope & Python Consulting - http://www.simplistix.co.uk
Jim Fulton wrote:
On Apr 2, 2009, at 2:31 PM, Chris Withers wrote:
For me, the ideal would be simply https for everything and using http basic auth for access with more people having access to update the passwd file and maybe Trac or WebSVN for a nice web interface.
I absolutely *hate* using https to access subversion.
Well, I absolutely *hate* using ssh to access subversion.
This involves storing a key in plane text in my home directory, which is terrible.
How do you not have the same thing with ssh? Myself, I work from a variety of machines on a variety of different platforms, and trying to juggle multiple public keys with undocumented and unsupported upload facilities is painful. The alternative is to try and juggle one public key across multiple machines and ssh implementations which is just as painful, not to mention insecure.
I far prefer using ssh-based infrastructure for this sort of thing.
I prefer using password-protected (as opposed to key-protected) https. What do other people prefer? Chris -- Simplistix - Content Management, Zope & Python Consulting - http://www.simplistix.co.uk
On Apr 2, 2009, at 2:44 PM, Chris Withers wrote:
This involves storing a key in plane text in my home directory, which is terrible.
How do you not have the same thing with ssh?
ssh keys are pass-phrase protected and ssh-agent allows me to enter the pass phrase once in a session. Jim -- Jim Fulton Zope Corporation
Chris Withers wrote at 2009-4-2 19:44 +0100:
... I prefer using password-protected (as opposed to key-protected) https. What do other people prefer?
I am fine with the "ssh" access. True, the initial setup was a bit difficult (the key program did not like the "." in "d.maurer" -- but forgot to tell so) but Jim spare enough time to help me overcome the problem. After I changed my username from "d.maurer" to "dmaurer", everything worked immediately. I would not like to enter my password every time I call "svn". If this can be arranged, I am content. -- Dieter
Dieter Maurer wrote:
I would not like to enter my password every time I call "svn". If this can be arranged, I am content.
It can, and with svn 1.6 it's even secure :-) Chris -- Simplistix - Content Management, Zope & Python Consulting - http://www.simplistix.co.uk
Jim Fulton wrote:
On Apr 2, 2009, at 2:31 PM, Chris Withers wrote:
For me, the ideal would be simply https for everything and using http basic auth for access with more people having access to update the passwd file and maybe Trac or WebSVN for a nice web interface.
I absolutely *hate* using https to access subversion. This involves storing a key in plane text in my home directory, which is terrible. I far prefer using ssh-based infrastructure for this sort of thing.
For write access I completely agree. For read-only unauthenticated access it would be nice to be able to use http(s). It may be possible to have it all at the same time. - Jacob
Jacob Holm wrote at 2009-4-2 20:44 +0200:
... For write access I completely agree. For read-only unauthenticated access it would be nice to be able to use http(s). It may be possible to have it all at the same time.
I have been told that there are mirrors of the Zope SVN repository providing read access via "http". -- Dieter
Dieter Maurer wrote:
I have been told that there are mirrors of the Zope SVN repository providing read access via "http".
Shame none of them is advertised anywhere... Chris -- Simplistix - Content Management, Zope & Python Consulting - http://www.simplistix.co.uk
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 02.04.2009 21:58 Uhr, Chris Withers wrote:
Dieter Maurer wrote:
I have been told that there are mirrors of the Zope SVN repository providing read access via "http".
Shame none of them is advertised anywhere...
http://svn.zope.de - -aj -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAknVGgYACgkQCJIWIbr9KYye6ACfXPCLs+nZPOKbupSZ3aJ0nWtT Pz0Ani9kEtzGwaxyoixsGFkdWOWbkhnB =fvsT -----END PGP SIGNATURE-----
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 02.04.2009 20:39 Uhr, Jim Fulton wrote:
On Apr 2, 2009, at 2:31 PM, Chris Withers wrote:
For me, the ideal would be simply https for everything and using http basic auth for access with more people having access to update the passwd file and maybe Trac or WebSVN for a nice web interface.
I absolutely *hate* using https to access subversion. This involves storing a key in plane text in my home directory, which is terrible. I far prefer using ssh-based infrastructure for this sort of thing.
Really? I have never stored a plain text password for SVN over https within my home dir. I also can not find anything related within .subversion/ in my home dir. Andreas -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAknVB6MACgkQCJIWIbr9KYy/OwCgvp2OPXzv/VFF2N09/fza6092 wiAAnRujl2mx2SRiviWclhWfnpDpiCqQ =xYXr -----END PGP SIGNATURE-----
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 02.04.2009 20:44 Uhr, Andreas Jung wrote:
On 02.04.2009 20:39 Uhr, Jim Fulton wrote:
On Apr 2, 2009, at 2:31 PM, Chris Withers wrote:
For me, the ideal would be simply https for everything and using http basic auth for access with more people having access to update the passwd file and maybe Trac or WebSVN for a nice web interface.
I absolutely *hate* using https to access subversion. This involves storing a key in plane text in my home directory, which is terrible. I far prefer using ssh-based infrastructure for this sort of thing.
Really? I have never stored a plain text password for SVN over https within my home dir. I also can not find anything related within .subversion/ in my home dir.
Possibly because I am using SVN 1.6. Andreas -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAknVCFkACgkQCJIWIbr9KYzIFgCgnUMYfD6ed/Lrro1Kqa5lHyr7 47YAn1pkzCaXk4PrxjLmxAooav7JM0wl =N9xl -----END PGP SIGNATURE-----
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Andreas Jung wrote:
On 02.04.2009 20:44 Uhr, Andreas Jung wrote:
On 02.04.2009 20:39 Uhr, Jim Fulton wrote:
On Apr 2, 2009, at 2:31 PM, Chris Withers wrote:
For me, the ideal would be simply https for everything and using http basic auth for access with more people having access to update the passwd file and maybe Trac or WebSVN for a nice web interface. I absolutely *hate* using https to access subversion. This involves storing a key in plane text in my home directory, which is terrible. I far prefer using ssh-based infrastructure for this sort of thing.
Really? I have never stored a plain text password for SVN over https within my home dir. I also can not find anything related within .subversion/ in my home dir.
Possibly because I am using SVN 1.6.
Then "never" means since 2009-03-20. Or else you have never done a checkout from a password-protected SVN-over-HTTP(S) server. Tres, - -- =================================================================== Tres Seaver +1 540-429-0999 tseaver@palladion.com Palladion Software "Excellence by Design" http://palladion.com -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFJ1QqA+gerLs4ltQ4RAqp3AKCOse88Q5aHlgI3tZguCFveN+Uc7wCgqRB2 tbMxeMww1fYarBzC+1k01Eo= =cj6O -----END PGP SIGNATURE-----
Tres Seaver wrote:
Possibly because I am using SVN 1.6.
Then "never" means since 2009-03-20. Or else you have never done a checkout from a password-protected SVN-over-HTTP(S) server.
It's been encrypted on Windows for longer than that... (svn 1.4...) Chris -- Simplistix - Content Management, Zope & Python Consulting - http://www.simplistix.co.uk
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 First, this cross-post was inappropriate: it is a matter for general discussion among Zope committers, which is not a matter for the Foundation to act on unless / until some consensus for changing the status quo emerges. This will be my last post to the 'foundation@zope.org' list on this thres. Chris Withers wrote:
I got bitten by the current zope subversion setup at PyCon so thought I'd mail the appropriate groups about it. If this has been covered elsewhere and I've missed anything, please just point me in the right direction...
So, svn.zope.org causes me pain at the moment:
- it uses the bizarre svn or svn+ssh protocols, which I find annoying (ports blocked on routers, can't check with a browser, etc)
/me shrugs. SSH is an essential part of my day-to-day work: not being able to use it means I'm effectively offline.
- the web front end is ancient and not as good as other options (Trac, WebSVN)
Fixing the web front-end should be a matter for the zope-web list.
- the process for adding keys is baroque and managed by one person who is too busy to help with it (Jim)
*This* part needs some fixing, largely because Jim's role their is an artifact of ZC's role, now lapsed, as custodians. At a minimum, there should be a group (I suggest the zope-web regulars) who can take over the maintenance of that application. A *different* group should have the role of collecting / approving the committer access requests.
So I thought I'd ask what the plans are now that the foundation owns all the Zope IP (has this happened yet or am I imagining things?)
The foundation now owns the copyrights. Trademarks are still in other hands.
Are we sticking with svn? Are we sticking with the current hosting? Are we sticking with the current key-based login and upload mechanism?
For me, the ideal would be simply https for everything and using http basic auth for access with more people having access to update the passwd file and maybe Trac or WebSVN for a nice web interface.
I volunteer to help with any/all of the above.
The other option would be to follow Python and move to Mercurial, but that has the same problems for me as with Bzr (no decent gui tools, less mature, etc) although it's a toolset I'll have to learn at some point anyway...
+1 to sticking with svn+ssh for write requests. - -1 to non-pubkey-based authentication for write requests. +1 to making svn-over-http read-only checkouts work. - -1 to switching away from svn, at least until the Python developers have some experience with the transition (I would wait at least 6 months). Tres. - -- =================================================================== Tres Seaver +1 540-429-0999 tseaver@palladion.com Palladion Software "Excellence by Design" http://palladion.com -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFJ1SXm+gerLs4ltQ4RAt74AJ93TlHe0VZ4vbAI706kDQzT8IvrkACfdzNP HrZb19KJDG+En2Zx+nRjz5c= =kLgg -----END PGP SIGNATURE-----
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Apr 2, 2009, at 22:53 , Tres Seaver wrote:
+1 to making svn-over-http read-only checkouts work.
This is now working. The repository can be reached under... http://svn.zope.org/repos/main/ jens -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.8 (Darwin) iEYEARECAAYFAknVNjQACgkQRAx5nvEhZLLKzACfROrQxGjCo1x90az9/HCMGBk9 JjcAoLAbxTarJVv1+f3jikTGBK1MBlpm =jZ+o -----END PGP SIGNATURE-----
Jens Vagelpohl wrote:
On Apr 2, 2009, at 22:53 , Tres Seaver wrote:
+1 to making svn-over-http read-only checkouts work.
This is now working. The repository can be reached under...
Jens, you're my hero :-) Remind me that I owe you beer next time I see you... Chris -- Simplistix - Content Management, Zope & Python Consulting - http://www.simplistix.co.uk
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 02.04.2009 22:53 Uhr, Tres Seaver wrote:
*This* part needs some fixing, largely because Jim's role their is an artifact of ZC's role, now lapsed, as custodians. At a minimum, there should be a group (I suggest the zope-web regulars) who can take over the maintenance of that application. A *different* group should have the role of collecting / approving the committer access requests.
I agree that this part definitely needs to be fixed. I updated the developer documentation in order to point to the foundations's about page as primary contact (suggested by Jens): http://docs.zope.org/developer/becoming-a-contributor.html (possibly not reflecting my changes made to the reST documents in SVN right now). Andreas -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAknVjFwACgkQCJIWIbr9KYwQRQCfRRVjxVylBA67tX+lhK3UG/ra ZHsAoKeaQGkNV/JUUKvfB00UFPpJ/D/6 =catZ -----END PGP SIGNATURE-----
Andreas Jung wrote:
*This* part needs some fixing, largely because Jim's role their is an artifact of ZC's role, now lapsed, as custodians. At a minimum, there should be a group (I suggest the zope-web regulars) who can take over the maintenance of that application. A *different* group should have the role of collecting / approving the committer access requests.
They'll end up being the same group pretty quickly, volunteers are thin on the ground :-/
I agree that this part definitely needs to be fixed. I updated the developer documentation in order to point to the foundations's about page as primary contact (suggested by Jens):
http://docs.zope.org/developer/becoming-a-contributor.html
(possibly not reflecting my changes made to the reST documents in SVN right now).
I did some cleanup on these docs this afternoon, including removing a couple of references to the (now removed) account.php script. cheers, Chris -- Simplistix - Content Management, Zope & Python Consulting - http://www.simplistix.co.uk
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Chris Withers wrote:
Andreas Jung wrote:
*This* part needs some fixing, largely because Jim's role their is an artifact of ZC's role, now lapsed, as custodians. At a minimum, there should be a group (I suggest the zope-web regulars) who can take over the maintenance of that application. A *different* group should have the role of collecting / approving the committer access requests.
They'll end up being the same group pretty quickly, volunteers are thin on the ground :-/
Maybe, but the one group is doing "policy" (who should be a committer?), while the other is doing "mechanism" (get approved committers set up). The groups don't have to overlap, as long as the workflow is clear. Tres. - -- =================================================================== Tres Seaver +1 540-429-0999 tseaver@palladion.com Palladion Software "Excellence by Design" http://palladion.com -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFJ1l1W+gerLs4ltQ4RAkpoAKCodutcQ4SqhReTJOCFbNkHo67W/gCggtDG /E4Mx4ojLHKH6etlKLxc9ko= =beMU -----END PGP SIGNATURE-----
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 03.04.2009 21:02 Uhr, Tres Seaver wrote:
Chris Withers wrote:
Andreas Jung wrote:
*This* part needs some fixing, largely because Jim's role their is an artifact of ZC's role, now lapsed, as custodians. At a minimum, there should be a group (I suggest the zope-web regulars) who can take over the maintenance of that application. A *different* group should have the role of collecting / approving the committer access requests. They'll end up being the same group pretty quickly, volunteers are thin on the ground :-/
Maybe, but the one group is doing "policy" (who should be a committer?), while the other is doing "mechanism" (get approved committers set up). The groups don't have to overlap, as long as the workflow is clear.
The Plone folks use a bugtracker for managing the committer access. A new contributor has to file a new ticket. A similar approach might be suited for managing new Zope committers. Speaking in workflow terms: a policy group could "accept" or "reject" the request. The mechanism group will deal with setting up the stuff for the committer and "close"-ing the case. Andreas -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAknWYSMACgkQCJIWIbr9KYxa4wCfdMbn7xVwowTRTVY9GlRAPMJ9 Mk4AmweFBudg2Z7XHA7JVfrMDVX2fLsk =eB1A -----END PGP SIGNATURE-----
Tres Seaver wrote:
- the web front end is ancient and not as good as other options (Trac, WebSVN)
Fixing the web front-end should be a matter for the zope-web list.
The zope-web list is pretty dead...
So I thought I'd ask what the plans are now that the foundation owns all the Zope IP (has this happened yet or am I imagining things?)
The foundation now owns the copyrights. Trademarks are still in other hands.
This is why I was cc'ing in the foundation list, there is relevant stuff for the foundation group in this discussion...
The other option would be to follow Python and move to Mercurial, but that has the same problems for me as with Bzr (no decent gui tools, less mature, etc) although it's a toolset I'll have to learn at some point anyway...
+1 to sticking with svn+ssh for write requests.
- -1 to non-pubkey-based authentication for write requests.
ParseError: what does the above line mean?
+1 to making svn-over-http read-only checkouts work.
- -1 to switching away from svn, at least until the Python developers have some experience with the transition (I would wait at least 6 months).
ParseError: what does the above line mean? Chris -- Simplistix - Content Management, Zope & Python Consulting - http://www.simplistix.co.uk
On Thu, Apr 02, 2009 at 07:31:00PM +0100, Chris Withers wrote:
So, svn.zope.org causes me pain at the moment:
- it uses the bizarre svn or svn+ssh protocols, which I find annoying (ports blocked on routers, can't check with a browser, etc)
+10 for continuing to support svn+ssh, it's the best thing ever! * secure (passphrase-protected key) * convenient (ssh-agent means you only type the passphrase once) * convenient to use remotely (ssh agent forwarding means I ssh into a remote server and can use svn without having to store a key or a password anywhere on that remote server) The story may be different for Windows users (as usual). +0.5 for alternatively accepting authenticated https access (I'm not the admin, so it doesn't cost me, but I'm also not going to use it) BTW I've yet to see a firewall that blocks SSH. Am I lucky?
- the web front end is ancient and not as good as other options (Trac, WebSVN)
+1 for having trac as a subversion browser. In fact, see http://zope3.pov.lt/trac The svn repository mirror used by that trac instance is updated with svnsync every 5 minutes.
- the process for adding keys is baroque and managed by one person who is too busy to help with it (Jim)
I would not mind spending some time in a sprint writing a Zope 3 svn key management web app, but that's only a small part of the solution. Authentication and deployment are the other---bigger--two parts. Marius Gedminas -- http://pov.lt/ -- Zope 3 consulting and development
On Apr 2, 2009, at 6:34 PM, Marius Gedminas wrote:
- the web front end is ancient and not as good as other options (Trac, WebSVN)
+1 for having trac as a subversion browser.
In fact, see http://zope3.pov.lt/trac
The svn repository mirror used by that trac instance is updated with svnsync every 5 minutes
Should we all just use that? Jim -- Jim Fulton Zope Corporation
On Fri, Apr 3, 2009 at 14:41, Jim Fulton <jim@zope.com> wrote:
Should we all just use that?
It's running trac 0.10. I'd love to see trac 0.11, which has additional features that I miss every time I use a 0.10 trac instance, such as the annotate view. Also, I'd include the subversion location plugin, which includes a link to the http:// or svn+ssh:// url for the currently viewed location, for easy checking out. -- Martijn Pieters
On Fri, Apr 03, 2009 at 03:04:47PM +0200, Martijn Pieters wrote:
On Fri, Apr 3, 2009 at 14:41, Jim Fulton <jim@zope.com> wrote:
Should we all just use that?
(that being http://zope3.pov.lt/trac) Sure, I don't mind. It sits behind an ADSL line with puny uplink (512 Kbit/s), but I don't think that will be a problem.
It's running trac 0.10. I'd love to see trac 0.11, which has additional features that I miss every time I use a 0.10 trac instance, such as the annotate view.
Trac 0.11 has annotate? *WANT*
Also, I'd include the subversion location plugin, which includes a link to the http:// or svn+ssh:// url for the currently viewed location, for easy checking out.
Sounds good. I'll look into this some time soon. Ping me in a week or so if I forget. Marius Gedminas -- http://pov.lt/ -- Zope 3 consulting and development
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 03.04.2009 17:22 Uhr, Marius Gedminas wrote:
On Fri, Apr 03, 2009 at 03:04:47PM +0200, Martijn Pieters wrote:
On Fri, Apr 3, 2009 at 14:41, Jim Fulton <jim@zope.com> wrote:
Should we all just use that?
(that being http://zope3.pov.lt/trac)
Sure, I don't mind. It sits behind an ADSL line with puny uplink (512 Kbit/s), but I don't think that will be a problem.
Nothing against your generous offer but I think that trac belongs as a central service on the central repository server. Andreas -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAknWKqsACgkQCJIWIbr9KYzcDgCfaKnN7ogpElGw4JoaRENrlCi4 Kf0AnjeaWL88tkrB4taIzL4/KczpQc9U =8ugy -----END PGP SIGNATURE-----
Andreas Jung wrote:
Sure, I don't mind. It sits behind an ADSL line with puny uplink (512 Kbit/s), but I don't think that will be a problem.
Nothing against your generous offer but I think that trac belongs as a central service on the central repository server.
+1, although if we were to give Marius access to the box, I'm sure he could set it up there and we'd all get what we want (including Marius desire to do the work ;-) ) cheers, Chris -- Simplistix - Content Management, Zope & Python Consulting - http://www.simplistix.co.uk
Marius Gedminas wrote:
The story may be different for Windows users (as usual).
+0.5 for alternatively accepting authenticated https access (I'm not the admin, so it doesn't cost me, but I'm also not going to use it)
BTW I've yet to see a firewall that blocks SSH. Am I lucky?
Yup.
In fact, see http://zope3.pov.lt/trac
The svn repository mirror used by that trac instance is updated with svnsync every 5 minutes.
Wouldn't it be great if you didn't have to do the mirroring (which must do a bit of pounding on svn.zope.org)
I would not mind spending some time in a sprint writing a Zope 3 svn key management web app, but that's only a small part of the solution. Authentication and deployment are the other---bigger--two parts.
Yes, this was why I was asking on the Foundation list: I want to know what's happening about what machines get used for this stuff... Chris -- Simplistix - Content Management, Zope & Python Consulting - http://www.simplistix.co.uk
Previously Marius Gedminas wrote:
BTW I've yet to see a firewall that blocks SSH. Am I lucky?
Yes. Blocking ssh is very common in larger companies in me experience. Wichert. -- Wichert Akkerman <wichert@wiggy.net> It is simple to make things. http://www.wiggy.net/ It is hard to make things simple.
Wichert Akkerman wrote:
Previously Marius Gedminas wrote:
BTW I've yet to see a firewall that blocks SSH. Am I lucky?
Yes. Blocking ssh is very common in larger companies in me experience.
An ssh server running on port 443 (HTTPS) can come in very handy. ssh -D gives you a socks proxy, tsocks makes using this transparent (e.g. tsocks bin/buildout). Failing that, 3G modems are quite reasonable nowdays. Laurence
My 2 cents: I like svn over https. It works reliably, and is easy to use, and externals work as expected, etcs. So I'm +1 on allowing https access. That said, svn+ssh tunnels svn over ssh, and if you are in a place where ssh doesn't work, you need to find the network admit and punch him in the face. -- Lennart Regebro: Pythonista, Barista, Notsotrista. http://regebro.wordpress.com/ +33 661 58 14 64
Laurence Rowe wrote:
Previously Marius Gedminas wrote:
BTW I've yet to see a firewall that blocks SSH. Am I lucky? Yes. Blocking ssh is very common in larger companies in me experience.
An ssh server running on port 443 (HTTPS) can come in very handy. ssh -D gives you a socks proxy, tsocks makes using this transparent (e.g. tsocks bin/buildout). Failing that, 3G modems are quite reasonable nowdays.
I'd like to see you do either of these two tricks on a big corporate's network, particularly the latter, for any length of time and keep your job... Chris -- Simplistix - Content Management, Zope & Python Consulting - http://www.simplistix.co.uk
2009/4/6 Chris Withers <chris@simplistix.co.uk>:
Laurence Rowe wrote:
Previously Marius Gedminas wrote:
BTW I've yet to see a firewall that blocks SSH. Am I lucky?
Yes. Blocking ssh is very common in larger companies in me experience.
An ssh server running on port 443 (HTTPS) can come in very handy. ssh -D gives you a socks proxy, tsocks makes using this transparent (e.g. tsocks bin/buildout). Failing that, 3G modems are quite reasonable nowdays.
I'd like to see you do either of these two tricks on a big corporate's network, particularly the latter, for any length of time and keep your job...
Nah, this would only be a problem if you worked with the IT department, everyone else prefers that you get more work done. Obviously with the 3G card my laptop was not connected to the network. Laurence
Marius Gedminas wrote at 2009-4-3 01:34 +0300:
On Thu, Apr 02, 2009 at 07:31:00PM +0100, Chris Withers wrote:
So, svn.zope.org causes me pain at the moment:
- it uses the bizarre svn or svn+ssh protocols, which I find annoying (ports blocked on routers, can't check with a browser, etc)
+10 for continuing to support svn+ssh, it's the best thing ever!
* secure (passphrase-protected key) * convenient (ssh-agent means you only type the passphrase once) * convenient to use remotely (ssh agent forwarding means I ssh into a remote server and can use svn without having to store a key or a password anywhere on that remote server)
The story may be different for Windows users (as usual).
+0.5 for alternatively accepting authenticated https access (I'm not the admin, so it doesn't cost me, but I'm also not going to use it)
Unless newer SVN versions improved on this: using different access protocols is hampered by "svn:external" as they were (still are?) required to be absolute urls (including the protocal). This way, the access protocol may change in between of a checkout (involving "svn:external"s). -- Dieter
Dieter Maurer wrote:
Unless newer SVN versions improved on this: using different access protocols is hampered by "svn:external" as they were (still are?) required to be absolute urls (including the protocal).
This way, the access protocol may change in between of a checkout (involving "svn:external"s).
svn:externals can be relative in many ways since SVN 1.5. Hanno
Hanno Schlichting wrote:
Dieter Maurer wrote:
Unless newer SVN versions improved on this: using different access protocols is hampered by "svn:external" as they were (still are?) required to be absolute urls (including the protocal).
This way, the access protocol may change in between of a checkout (involving "svn:external"s).
svn:externals can be relative in many ways since SVN 1.5.
Just beware, 1.5 sucks: http://subversion.tigris.org/issues/show_bug.cgi?id=3242 http://thread.gmane.org/gmane.comp.version-control.subversion.user/84308/foc... http://thread.gmane.org/gmane.comp.version-control.subversion.user/87346/foc... Chris -- Simplistix - Content Management, Zope & Python Consulting - http://www.simplistix.co.uk
On Mon, Apr 6, 2009 at 10:32, Chris Withers <chris@simplistix.co.uk> wrote:
Just beware, 1.5 sucks:
http://subversion.tigris.org/issues/show_bug.cgi?id=3242 http://thread.gmane.org/gmane.comp.version-control.subversion.user/84308/foc... http://thread.gmane.org/gmane.comp.version-control.subversion.user/87346/foc...
It sucks for very specific cases, namely tight access control on sub-paths. I don't see such cases, and I see speed improvements instead. Note that we are now up to svn 1.6. -- Martijn Pieters
Martijn Pieters wrote:
On Mon, Apr 6, 2009 at 10:32, Chris Withers <chris@simplistix.co.uk> wrote:
Just beware, 1.5 sucks:
http://subversion.tigris.org/issues/show_bug.cgi?id=3242 http://thread.gmane.org/gmane.comp.version-control.subversion.user/84308/foc... http://thread.gmane.org/gmane.comp.version-control.subversion.user/87346/foc...
It sucks for very specific cases, namely tight access control on sub-paths.
I'm more worried about the lack of merging working and random errors when adding files. Those are pretty serious failures from where I'm sitting... Chris -- Simplistix - Content Management, Zope & Python Consulting - http://www.simplistix.co.uk
On Mon, Apr 6, 2009 at 10:39, Chris Withers <chris@simplistix.co.uk> wrote:
I'm more worried about the lack of merging working and random errors when adding files. Those are pretty serious failures from where I'm sitting...
The merging is due to lack of merging info when branching, the 'random errors' are not random but due to svn info being out-of-date after a commit. svn up has always solved that for me. Yes, the latter is a bug, but I suspect it is already solved in 1.6 (didn't test that yet though). -- Martijn Pieters
Previously Martijn Pieters wrote:
On Mon, Apr 6, 2009 at 10:32, Chris Withers <chris@simplistix.co.uk> wrote:
Just beware, 1.5 sucks:
http://subversion.tigris.org/issues/show_bug.cgi?id=3242 http://thread.gmane.org/gmane.comp.version-control.subversion.user/84308/foc... http://thread.gmane.org/gmane.comp.version-control.subversion.user/87346/foc...
It sucks for very specific cases, namely tight access control on sub-paths. I don't see such cases, and I see speed improvements instead.
Note that we are now up to svn 1.6.
Which still does not fix this, and is preventing people from upgrading to the 1.5 client, and thus from using checkouts using relative paths. Wichert. -- Wichert Akkerman <wichert@wiggy.net> It is simple to make things. http://www.wiggy.net/ It is hard to make things simple.
On Mon, Apr 6, 2009 at 11:53, Wichert Akkerman <wichert@wiggy.net> wrote:
Note that we are now up to svn 1.6.
Which still does not fix this, and is preventing people from upgrading to the 1.5 client, and thus from using checkouts using relative paths.
Bugger, that is indeed correct. I may not have any problems (and a workaround for svn bug 3119) but that doesn't mean we can ask other people that need access to more tightly ACL-ed repositories to put up with subversion 1.5 and 1.6. -- Martijn Pieters
Martijn Pieters wrote:
On Mon, Apr 6, 2009 at 11:53, Wichert Akkerman <wichert@wiggy.net> wrote:
Note that we are now up to svn 1.6. Which still does not fix this, and is preventing people from upgrading to the 1.5 client, and thus from using checkouts using relative paths.
Bugger, that is indeed correct. I may not have any problems (and a workaround for svn bug 3119) but that doesn't mean we can ask other people that need access to more tightly ACL-ed repositories to put up with subversion 1.5 and 1.6.
To be honest, the state of svn 1.5 is what's getting me to think about looking at mercurial. (bzr didn't take my fancy, and hg is gonna be used by the python-core folks, so I might as well learn that...) Sadly, I suspect none of the tools are as advanced as TortoiseSVN. Which is a real shame :-( Perforce maybe? ;-) Chris -- Simplistix - Content Management, Zope & Python Consulting - http://www.simplistix.co.uk
On Apr 6, 2009, at 6:51 AM, Chris Withers wrote:
Martijn Pieters wrote:
On Mon, Apr 6, 2009 at 11:53, Wichert Akkerman <wichert@wiggy.net> wrote:
Note that we are now up to svn 1.6. Which still does not fix this, and is preventing people from upgrading to the 1.5 client, and thus from using checkouts using relative paths.
Bugger, that is indeed correct. I may not have any problems (and a workaround for svn bug 3119) but that doesn't mean we can ask other people that need access to more tightly ACL-ed repositories to put up with subversion 1.5 and 1.6.
To be honest, the state of svn 1.5 is what's getting me to think about looking at mercurial.
(bzr didn't take my fancy, and hg is gonna be used by the python-core folks, so I might as well learn that...)
Sadly, I suspect none of the tools are as advanced as TortoiseSVN. Which is a real shame :-( Perforce maybe? ;-)
Fair enough that bzr didn't take your fancy, but FWIW, did you try TortoiseBzr? That has received love relatively recently. Gary
Gary Poster wrote:
Sadly, I suspect none of the tools are as advanced as TortoiseSVN. Which is a real shame :-( Perforce maybe? ;-)
Fair enough that bzr didn't take your fancy, but FWIW, did you try TortoiseBzr? That has received love relatively recently.
I'm looking at this: http://bazaar-vcs.org/TortoiseBzr/Screenshots Where's the visual diff? Where's the interactive log of revisions? Where's the repository browser? Does it work the same on Windows, Ubuntu and Mac OS? http://tortoisesvn.net/image/tid/13 gives a fair idea of the kinds of things I'd need to feel compelled to change... Chris -- Simplistix - Content Management, Zope & Python Consulting - http://www.simplistix.co.uk
On Apr 6, 2009, at 9:28 AM, Chris Withers wrote:
Gary Poster wrote:
Sadly, I suspect none of the tools are as advanced as TortoiseSVN. Which is a real shame :-( Perforce maybe? ;-) Fair enough that bzr didn't take your fancy, but FWIW, did you try TortoiseBzr? That has received love relatively recently.
I'm looking at this:
http://bazaar-vcs.org/TortoiseBzr/Screenshots
Where's the visual diff? Where's the interactive log of revisions? Where's the repository browser?
FWIW, I don't know if TortoiseBzr has this. I'd be surprised if it didn't have these, especially the first two. It would be cool if someone with easy access to Windows were to check this out. Otherwise, I'll give it a try eventually and report back myself. (If it has these features, I'll try to figure out someone to ask to get that page updated.)
Does it work the same on Windows, Ubuntu and Mac OS?
(I assume you mean bzr vs.svn, rather than TortoiseBzr vs. TortoiseSvn; AFAICT, Tortoise* is Windows only.) Well, the EOL problem has been the only bzr kicker there. That was just addressed, spurred most recently in part because of the concerns from the Zope community; I don't know if it is in 1.13 or the upcoming 1.14. Other than that, I think bzr cares a fair amount about Windows (and certainly about Ubuntu and Mac).
http://tortoisesvn.net/image/tid/13 gives a fair idea of the kinds of things I'd need to feel compelled to change...
Right. Looks nice enough. Gary
Gary Poster wrote:
Where's the visual diff? Where's the interactive log of revisions? Where's the repository browser?
FWIW, I don't know if TortoiseBzr has this. I'd be surprised if it didn't have these, especially the first two.
TortoiseSVN's log is now *very* interactive. I'd be surprised if TortoiseBzr *did* haev that level of interactivity, given how many years it took tsvn to grow it ;-)
Does it work the same on Windows, Ubuntu and Mac OS?
(I assume you mean bzr vs.svn, rather than TortoiseBzr vs. TortoiseSvn; AFAICT, Tortoise* is Windows only.)
No, I mean TortoiseBzr. As I said to Mark Hammond when chatting about Bzr, having a *great* gui tool equivalent to TortoiseSvn that worked *cross platform* would be a *major* reason to move to that rcs. Anything less is just "interesting". Chris -- Simplistix - Content Management, Zope & Python Consulting - http://www.simplistix.co.uk
On Sun, Apr 05, 2009 at 09:10:10AM +0200, Dieter Maurer wrote:
Marius Gedminas wrote at 2009-4-3 01:34 +0300:
On Thu, Apr 02, 2009 at 07:31:00PM +0100, Chris Withers wrote:
So, svn.zope.org causes me pain at the moment:
- it uses the bizarre svn or svn+ssh protocols, which I find annoying (ports blocked on routers, can't check with a browser, etc)
+10 for continuing to support svn+ssh, it's the best thing ever!
* secure (passphrase-protected key) * convenient (ssh-agent means you only type the passphrase once) * convenient to use remotely (ssh agent forwarding means I ssh into a remote server and can use svn without having to store a key or a password anywhere on that remote server)
The story may be different for Windows users (as usual).
+0.5 for alternatively accepting authenticated https access (I'm not the admin, so it doesn't cost me, but I'm also not going to use it)
Unless newer SVN versions improved on this: using different access protocols is hampered by "svn:external" as they were (still are?) required to be absolute urls (including the protocal).
This way, the access protocol may change in between of a checkout (involving "svn:external"s).
This is a very good point I'd forgotten about. However, currently the existing svn:externals all point to read-only svn:// URLs, and switching them to http:// would not change anything substantially. Subversion 1.5 lets you use relative URLs in svn:external, if you're willing to forgo compatibility with Subversion 1.4 clients. See http://svnbook.red-bean.com/en/1.5/svn.advanced.externals.html Marius Gedminas -- http://pov.lt/ -- Zope 3 consulting and development
On Sun, Apr 5, 2009 at 17:48, Marius Gedminas <marius@gedmin.as> wrote:
This is a very good point I'd forgotten about. However, currently the existing svn:externals all point to read-only svn:// URLs, and switching them to http:// would not change anything substantially.
Nope, but switching then to https:// would. But switching to relative URLs would also solve them problem. -- Lennart Regebro: Pythonista, Barista, Notsotrista. http://regebro.wordpress.com/ +33 661 58 14 64
On Apr 2, 2009, at 1:31 PM, Chris Withers wrote:
Hey All,
...
The other option would be to follow Python and move to Mercurial, but that has the same problems for me as with Bzr (no decent gui tools, less mature, etc) although it's a toolset I'll have to learn at some point anyway...
I'd like to report back on the progress that Bzr/Launchpad has made addressing concerns we heard since I last brought up Canonical's offer to host the code and contribute commercial support for the transition. When I do that, I'll do it on zope-dev, assuming that Tres' statement in this thread that we should discuss there is authoritative. (I thought the people on Foundations were the superset of people who commit to the repo, but I guess I was mistaken. Sorry for my misunderstanding.) However, I just got back from a long trip, and I'm going to spend some time with my family. I'll write something up to zope-dev tomorrow. Gary
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Gary Poster wrote:
I'd like to report back on the progress that Bzr/Launchpad has made addressing concerns we heard since I last brought up Canonical's offer to host the code and contribute commercial support for the transition.
When I do that, I'll do it on zope-dev, assuming that Tres' statement in this thread that we should discuss there is authoritative. (I thought the people on Foundations were the superset of people who commit to the repo, but I guess I was mistaken. Sorry for my misunderstanding.)
The foundation members are a *subset* of all committers, with sponsoring companies added on. There are under 50 "nominated members" (formerly "committer members", whereas there are something like 375 committers. Any decision to move the repository will need to be formally made by the foundation (via its board), but that would only happen if the consensus of the members and the wider community were clearly in favor of a move. Tres. - -- =================================================================== Tres Seaver +1 540-429-0999 tseaver@palladion.com Palladion Software "Excellence by Design" http://palladion.com -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFJ1VnB+gerLs4ltQ4RAtvVAJ4kPghyM3nlJGRNQN5vsJazrhR+6wCfZRui WwEbnYYd59eXJ9FOHYD9ZuM= =gtgH -----END PGP SIGNATURE-----
On Apr 2, 2009, at 7:35 PM, Tres Seaver wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Gary Poster wrote:
I'd like to report back on the progress that Bzr/Launchpad has made addressing concerns we heard since I last brought up Canonical's offer to host the code and contribute commercial support for the transition.
[snip saying I'll do it later, and apology for misunderstanding of Foundation membership]
The foundation members are a *subset* of all committers, with sponsoring companies added on. There are under 50 "nominated members" (formerly "committer members", whereas there are something like 375 committers.
Any decision to move the repository will need to be formally made by the foundation (via its board), but that would only happen if the consensus of the members and the wider community were clearly in favor of a move.
Good to know, thank you. Off to write the email... Gary
participants (16)
-
Andreas Jung -
Carsten Senger -
Chris Withers -
Christian Theune -
Dieter Maurer -
Gary Poster -
Hanno Schlichting -
Jacob Holm -
Jens Vagelpohl -
Jim Fulton -
Laurence Rowe -
Lennart Regebro -
Marius Gedminas -
Martijn Pieters -
Tres Seaver -
Wichert Akkerman