-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi, a long-standing issue with our mirror of svn.zope.org are the absolute URLs of externals: they require the repository to be available on a given URL. I propose to use relative URLs for externals. I guess a complete update isn't necessary, but I'd like to improve the situation and start using them from now on. Maybe we should also put a commit hook in place as a safety belt? However, this requires Subversion 1.5 which we are using on the server already, but I don't know whether we assume clients are 1.5 or higher. As a side effect this will also make svn/svn+ssh work in a nicer way (IMHO) as the externals will follow the protocol of what you used for checkout. Christian - -- Christian Theune · ct@gocept.com gocept gmbh & co. kg · forsterstraße 29 · 06112 halle (saale) · germany http://gocept.com · tel +49 345 1229889 0 · fax +49 345 1229889 1 Zope and Plone consulting and development -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkqnoB8ACgkQdUt9X/gknwI9lgCcDjO320EGllkcaJT8rA7aR+pa rVIAn2Qh5D7sIGMmNPSyClx72PHBhL80 =5696 -----END PGP SIGNATURE-----
On Wed, Sep 9, 2009 at 8:31 AM, Christian Theune<ct@gocept.com> wrote:
As a side effect this will also make svn/svn+ssh work in a nicer way (IMHO) as the externals will follow the protocol of what you used for checkout.
I like that externals to svn:... are read-only, though I don't know offhand whether we have a policy about this. -Fred -- Fred L. Drake, Jr. <fdrake at gmail.com> "Chaos is the score upon which reality is written." --Henry Miller
Hi there, Christian Theune wrote:
a long-standing issue with our mirror of svn.zope.org are the absolute URLs of externals: they require the repository to be available on a given URL.
I propose to use relative URLs for externals. I guess a complete update isn't necessary, but I'd like to improve the situation and start using them from now on. Maybe we should also put a commit hook in place as a safety belt?
However, this requires Subversion 1.5 which we are using on the server already, but I don't know whether we assume clients are 1.5 or higher.
I certainly still use a SVN 1.4.x client, being on Ubuntu 8.04 LTS (released just last year). I don't think SVN 1.5 is common enough yet to make such a move possible.
As a side effect this will also make svn/svn+ssh work in a nicer way (IMHO) as the externals will follow the protocol of what you used for checkout.
That's definitely cool; keeps tripping me up when I want to check into an external. Usually I use externals when I'm developing multiple things at once... So, I don't think it's time yet, but I do support this on the longer term. We could record a decision to do this at least for the ZTK in the ZTK decisions document. What about mid-next year for requiring Subversion 1.5.x? There's nothing against us deciding things well ahead of time! A ZTK timeline planning document, anyone? (Ubuntu should've released a new LTS by then too. :) Regards, Martijn
Martijn Faassen schrieb:
Hi there,
Christian Theune wrote:
a long-standing issue with our mirror of svn.zope.org are the absolute URLs of externals: they require the repository to be available on a given URL.
I propose to use relative URLs for externals. I guess a complete update isn't necessary, but I'd like to improve the situation and start using them from now on. Maybe we should also put a commit hook in place as a safety belt?
However, this requires Subversion 1.5 which we are using on the server already, but I don't know whether we assume clients are 1.5 or higher.
I certainly still use a SVN 1.4.x client, being on Ubuntu 8.04 LTS (released just last year). I don't think SVN 1.5 is common enough yet to make such a move possible.
you still can use 1.4 clients an a 1.5 server I think.. robert
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 robert rottermann wrote:
Martijn Faassen schrieb:
Hi there,
Christian Theune wrote:
a long-standing issue with our mirror of svn.zope.org are the absolute URLs of externals: they require the repository to be available on a given URL.
I propose to use relative URLs for externals. I guess a complete update isn't necessary, but I'd like to improve the situation and start using them from now on. Maybe we should also put a commit hook in place as a safety belt?
However, this requires Subversion 1.5 which we are using on the server already, but I don't know whether we assume clients are 1.5 or higher. I certainly still use a SVN 1.4.x client, being on Ubuntu 8.04 LTS (released just last year). I don't think SVN 1.5 is common enough yet to make such a move possible.
you still can use 1.4 clients an a 1.5 server I think..
I don't think such clients will be able to grok newer features (such as the proposed relative externals). 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 iD8DBQFKqAW/+gerLs4ltQ4RAqIgAKCHb+AVt3KDo4A+G5Qr0UXo5I0ErACgo1S0 nW8cF+T1Wq2AwkX8GG3Vjz0= =ubsl -----END PGP SIGNATURE-----
On Wed, Sep 9, 2009 at 2:40 PM, Martijn Faassen<faassen@startifact.com> wrote:
Christian Theune wrote:
However, this requires Subversion 1.5 which we are using on the server already, but I don't know whether we assume clients are 1.5 or higher.
I certainly still use a SVN 1.4.x client, being on Ubuntu 8.04 LTS (released just last year). I don't think SVN 1.5 is common enough yet to make such a move possible.
We moved all the Plone repositories (including the rather massively used collective) to Subversion 1.5.6 a while ago. So far there have been no complaints by anyone. And as Robert noted you can use a Subversion 1.4 client with a 1.5 server just fine. I think doing the server upgrade very soon (tm) shouldn't be a problem. Using relative externals or proper merge history might be something that shouldn't be required yet, though. Maybe people should be free and allowed to do this for any package not being part of the ZTK right away. That might introduce some incentive for those still using age-old Subversion clients ;) Hanno
Hanno Schlichting wrote:
On Wed, Sep 9, 2009 at 2:40 PM, Martijn Faassen<faassen@startifact.com> wrote:
Christian Theune wrote:
However, this requires Subversion 1.5 which we are using on the server already, but I don't know whether we assume clients are 1.5 or higher. I certainly still use a SVN 1.4.x client, being on Ubuntu 8.04 LTS (released just last year). I don't think SVN 1.5 is common enough yet to make such a move possible.
We moved all the Plone repositories (including the rather massively used collective) to Subversion 1.5.6 a while ago. So far there have been no complaints by anyone. And as Robert noted you can use a Subversion 1.4 client with a 1.5 server just fine.
I think doing the server upgrade very soon (tm) shouldn't be a problem.
Ah, I perhaps misunderstood. I figured the resolving of relative externals would be a problem with a Subversion 1.4.x client. Regards, Martijn
On Sep 9, 2009, at 15:30 , Martijn Faassen wrote:
Ah, I perhaps misunderstood. I figured the resolving of relative externals would be a problem with a Subversion 1.4.x client.
There's two different issues being confused here. SVN 1.4 clients will work with SVN 1.5 repositories in general. However, that's not the real issue here. The issue is the new-style externals definitions that allow you to use "relative" paths. Those relative paths will not work for SVN 1.4 clients. jens
On Wed, Sep 9, 2009 at 10:35 AM, Jens Vagelpohl<jens@dataflake.org> wrote:
SVN 1.4 clients will work with SVN 1.5 repositories in general. However, that's not the real issue here. The issue is the new-style externals definitions that allow you to use "relative" paths. Those relative paths will not work for SVN 1.4 clients.
Is that based on an assumption or someone tried and verified that it doesnt work? -- Sidnei
On Sep 9, 2009, at 15:59 , Sidnei da Silva wrote:
On Wed, Sep 9, 2009 at 10:35 AM, Jens Vagelpohl<jens@dataflake.org> wrote:
SVN 1.4 clients will work with SVN 1.5 repositories in general. However, that's not the real issue here. The issue is the new-style externals definitions that allow you to use "relative" paths. Those relative paths will not work for SVN 1.4 clients.
Is that based on an assumption or someone tried and verified that it doesnt work?
It doesn't. I tried. jens
Jens Vagelpohl wrote:
On Sep 9, 2009, at 15:30 , Martijn Faassen wrote:
Ah, I perhaps misunderstood. I figured the resolving of relative externals would be a problem with a Subversion 1.4.x client.
There's two different issues being confused here.
SVN 1.4 clients will work with SVN 1.5 repositories in general. However, that's not the real issue here. The issue is the new-style externals definitions that allow you to use "relative" paths. Those relative paths will not work for SVN 1.4 clients.
Okay, no objection to upgrading the server to 1.5 now. But requiring 1.5 as clients will need some more discussion. I take it there are two main reasons to do so: * relative URLs in externals * better merge tracking Regards, Martijn
On Sep 9, 2009, at 17:05 , Martijn Faassen wrote:
Jens Vagelpohl wrote:
SVN 1.4 clients will work with SVN 1.5 repositories in general. However, that's not the real issue here. The issue is the new-style externals definitions that allow you to use "relative" paths. Those relative paths will not work for SVN 1.4 clients.
Okay, no objection to upgrading the server to 1.5 now.
It's been 1.5 for a while now, so that can be excluded from any further discussion. This is a client-only problem. jens
On 09/09/2009 05:05 PM, Martijn Faassen wrote:
Jens Vagelpohl wrote:
On Sep 9, 2009, at 15:30 , Martijn Faassen wrote:
Ah, I perhaps misunderstood. I figured the resolving of relative externals would be a problem with a Subversion 1.4.x client.
There's two different issues being confused here.
SVN 1.4 clients will work with SVN 1.5 repositories in general. However, that's not the real issue here. The issue is the new-style externals definitions that allow you to use "relative" paths. Those relative paths will not work for SVN 1.4 clients.
Okay, no objection to upgrading the server to 1.5 now.
That has been done a good while ago already (I was probably ambiguous in my mail).
But requiring 1.5 as clients will need some more discussion. I take it there are two main reasons to do so:
* relative URLs in externals
* better merge tracking
For some interpretation of "better". -- Christian Theune · ct@gocept.com gocept gmbh & co. kg · forsterstraße 29 · 06112 halle (saale) · germany http://gocept.com · tel +49 345 1229889 0 · fax +49 345 1229889 1 Zope and Plone consulting and development
On Wed, Sep 9, 2009 at 6:40 PM, Christian Theune<ct@gocept.com> wrote:
On 09/09/2009 05:05 PM, Martijn Faassen wrote:
Okay, no objection to upgrading the server to 1.5 now.
That has been done a good while ago already (I was probably ambiguous in my mail).
Damn, Jens is just doing too much of an awesome job and not talking about it ;)
But requiring 1.5 as clients will need some more discussion. I take it there are two main reasons to do so:
* relative URLs in externals
* better merge tracking
For some interpretation of "better".
"better" as in "merge tracking exists now vs. there was nothing so far". I wouldn't call the merge tracking great in any way, but it is better than the previous state of having nothing at all. But then again most of Zope doesn't have many active branches, except for Zope2 and CMF maybe. Most packages only have a maintained trunk, so this isn't so relevant. Hanno
On Wed, Sep 9, 2009 at 12:40 PM, Christian Theune<ct@gocept.com> wrote:
On 09/09/2009 05:05 PM, Martijn Faassen wrote:
* better merge tracking
For some interpretation of "better".
My team tried pretty hard to use 1.5's merge tracking and we could never get it to work well for us. The only advantage we ended up seeing was that we could "freshen" a branch from a trunk easily. Even that didn't buy us much because we previously had been using the relatively easy approach of "rebranching" from the trunkand merging from the stale branch to the new, fresh branch. The limitation of only being able to merge a feature branch back to the trunk once was also quite irritating. Plus the merge info properties constantly polluted "svn diff" and "svn stat" output as well as our commit email (the latter is fixable of course). After trying for a few months we abandoned it. YMMV. -- Benji York Senior Software Engineer Zope Corporation
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 09/09/2009 07:12 PM, Benji York wrote:
On Wed, Sep 9, 2009 at 12:40 PM, Christian Theune<ct@gocept.com> wrote:
On 09/09/2009 05:05 PM, Martijn Faassen wrote:
* better merge tracking
For some interpretation of "better".
My team tried pretty hard to use 1.5's merge tracking and we could never get it to work well for us.
The only advantage we ended up seeing was that we could "freshen" a branch from a trunk easily. Even that didn't buy us much because we previously had been using the relatively easy approach of "rebranching" from the trunkand merging from the stale branch to the new, fresh branch.
The limitation of only being able to merge a feature branch back to the trunk once was also quite irritating.
Plus the merge info properties constantly polluted "svn diff" and "svn stat" output as well as our commit email (the latter is fixable of course).
After trying for a few months we abandoned it. YMMV.
Same here. We also ended up in many deadlock situations having to sacrifice chickens for SVN to resume operations. That's why we started investigating alternatives which are better at branching and merging. Christian - -- Christian Theune · ct@gocept.com gocept gmbh & co. kg · forsterstraße 29 · 06112 halle (saale) · germany http://gocept.com · tel +49 345 1229889 0 · fax +49 345 1229889 1 Zope and Plone consulting and development -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkqok5YACgkQdUt9X/gknwLr+QCdHHnFGExGT3E3FFgVmKqow78g y6AAn3ent24aED7DzH8gdN+XDMdJ/tLQ =Zhv/ -----END PGP SIGNATURE-----
Hey, Christian Theune wrote: [snip]
Same here. We also ended up in many deadlock situations having to sacrifice chickens for SVN to resume operations. That's why we started investigating alternatives which are better at branching and merging.
Please keep up posted. We have a standing offer from Canonical to host our stuff in bzr. The move of the Python core developers to mercurial is also interesting. Regards, Martijn
Martijn Faassen wrote:
Christian Theune wrote: [snip]
Same here. We also ended up in many deadlock situations having to sacrifice chickens for SVN to resume operations. That's why we started investigating alternatives which are better at branching and merging.
Please keep up posted. We have a standing offer from Canonical to host our stuff in bzr. The move of the Python core developers to mercurial is also interesting.
I've been impressed with TortoiseHg so far (after a few initial hiccups) and it looks like they're aiming to be cross platform with it, which is a pretty big draw, although the MacOS port isn't ready yet... How has TortoiseBzr progressed? cheers, Chris -- Simplistix - Content Management, Batch Processing & Python Consulting - http://www.simplistix.co.uk
On Sep 11, 2009, at 9:34 AM, Chris Withers wrote:
Martijn Faassen wrote:
Christian Theune wrote: [snip]
Same here. We also ended up in many deadlock situations having to sacrifice chickens for SVN to resume operations. That's why we started investigating alternatives which are better at branching and merging.
Please keep up posted. We have a standing offer from Canonical to host our stuff in bzr. The move of the Python core developers to mercurial is also interesting.
I've been impressed with TortoiseHg so far (after a few initial hiccups) and it looks like they're aiming to be cross platform with it, which is a pretty big draw, although the MacOS port isn't ready yet...
How has TortoiseBzr progressed?
My understanding is that TortoiseBzr has largely withered on the vine in favor of a new effort: BzrExplorer, based on Qt, and running on Linux/Windows/Mac. http://bazaar-vcs.org/BzrExplorer That page has links to lots of information. The very little information I have is based on those pages, so, for now, please look there for now rather than asking me anything. Once Bzr 2.0 comes out (in less than a month AIUI), I'll at least send out a link to it and point out some changes made that specifically address concerns raised by Zope Foundation members when I raised Launchpad's/Canonical's offer before. If there are any questions then, I'll be happy to try to get answers. Gary
On 14.09.09 20:02, Gary Poster wrote:
On Sep 11, 2009, at 9:34 AM, Chris Withers wrote:
Martijn Faassen wrote:
Christian Theune wrote: [snip]
Same here. We also ended up in many deadlock situations having to sacrifice chickens for SVN to resume operations. That's why we started investigating alternatives which are better at branching and merging.
Please keep up posted. We have a standing offer from Canonical to host our stuff in bzr. The move of the Python core developers to mercurial is also interesting.
I've been impressed with TortoiseHg so far (after a few initial hiccups) and it looks like they're aiming to be cross platform with it, which is a pretty big draw, although the MacOS port isn't ready yet...
How has TortoiseBzr progressed?
My understanding is that TortoiseBzr has largely withered on the vine in favor of a new effort: BzrExplorer, based on Qt, and running on Linux/Windows/Mac.
http://bazaar-vcs.org/BzrExplorer
That page has links to lots of information. The very little information I have is based on those pages, so, for now, please look there for now rather than asking me anything.
Once Bzr 2.0 comes out (in less than a month AIUI), I'll at least send out a link to it and point out some changes made that specifically address concerns raised by Zope Foundation members when I raised Launchpad's/Canonical's offer before. If there are any questions then, I'll be happy to try to get answers. One personal aspect I would like to throw into the discussion:
Although it is possible to use hg/bzr/svn in parallel within a project and a buildout, I am completely against having a mixture of SVN+HG or SVN+BZR within a Plone project (where Zope stuff is coming from BZR or HG) and the Plone stuff from SVN..if we want/need to switch away from SVN then all other related projects should switch as well. Andreas
Andreas Jung wrote:
Although it is possible to use hg/bzr/svn in parallel within a project and a buildout, I am completely against having a mixture of SVN+HG or SVN+BZR within a Plone project (where Zope stuff is coming from BZR or HG) and the Plone stuff from SVN..if we want/need to switch away from SVN then all other related projects should switch as well.
That's not our decision to make ;-) I agree about using homogeneous source control within a project, but if two dependencies of that project use different source control systems, it's trivial to take an export of one of them. In fact, this "vendor branch" policy is actually recommended by the subversion guys even if you're using the same source control system... cheers, Chris -- Simplistix - Content Management, Batch Processing & Python Consulting - http://www.simplistix.co.uk
On Sep 14, 2009, at 2:02 PM, Gary Poster wrote:
Once Bzr 2.0 comes out (in less than a month AIUI), I'll at least send out a link to it and point out some changes made that specifically address concerns raised by Zope Foundation members when I raised Launchpad's/Canonical's offer before. If there are any questions then, I'll be happy to try to get answers.
Bzr 2.0 is out. I personally find the speed improvements very impressive. The new repository format is much smaller, and intended to be stable, and the project has a adopted a six-month maintenance release approach. It has a new website. http://bazaar-vcs.org/en/ It has a new front-end for Gnome/KDE/Mac OS X/Win. The screenshots look impressive to me, which is all I can vouch for. http://doc.bazaar-vcs.org/explorer/en/visual-tour-windows.html Cross-platform end of line conversion is implemented, which was one of the concerns raised earlier. http://doc.bazaar-vcs.org/bzr.dev/en/user-reference/bzr_man.html#end-of-line... I don't remember if anyone brought up the lack of a parallel to svn externals. That functionality (called nested trees for bzr) is not implemented yet. It is important to Launchpad's usage of the tool, though, so it is in the six-month pipeline, as I understand it. I'm happy to try to field any questions if anyone has any. Gary
On Thu, Sep 10, 2009 at 16:58, Martijn Faassen <faassen@startifact.com> wrote: Hi Martjin
Hey,
Christian Theune wrote: [snip]
Same here. We also ended up in many deadlock situations having to sacrifice chickens for SVN to resume operations. That's why we started investigating alternatives which are better at branching and merging.
Here, we use Hg since 1 year and I'm really happy about that. I don't want use svn anymore.
The move of the Python core developers to mercurial is also interesting.
Caution with the actual workflow, 2 differences between SVN and Hg : - you cannot check out partial repository - external does not exist Cheers -- Sebastien Douche <sdouche@gmail.com> Twitter: http://bit.ly/afkrK (agile, python, open source)
On 2009-09-11, Sebastien Douche <sdouche@gmail.com> wrote:
Caution with the actual workflow, 2 differences between SVN and Hg : - you cannot check out partial repository - external does not exist
Missing externals has been a pain point for me. There are however buildout recipes that can pull in "externals" for you from buildout. infrae.subversion does it (and can turn the downloaded stuff into a development egg at the same time), Balasz Ree has a bzr recipe. I'm betting there's a mercurial one, also (and otherwise I'll build one if needed) :-) There remains a small pain point: you have to basically run buildout to update the "externals" in that way. A simple "svn up"/"bzr up"/etc doesn't update the externals... But there are of course lots of advantages to distributed systems that outweigh the small pain. So: missing externals are solveable if we all use buildout :-) Reinout -- Reinout van Rees - reinout@vanrees.org - http://reinout.vanrees.org Software developer at http://www.thehealthagency.com "Military engineers build missiles. Civil engineers build targets"
On 9/15/09 10:33 , Reinout van Rees wrote:
On 2009-09-11, Sebastien Douche<sdouche@gmail.com> wrote:
Caution with the actual workflow, 2 differences between SVN and Hg : - you cannot check out partial repository - external does not exist
Missing externals has been a pain point for me.
There are however buildout recipes that can pull in "externals" for you from buildout. infrae.subversion does it (and can turn the downloaded stuff into a development egg at the same time), Balasz Ree has a bzr recipe. I'm betting there's a mercurial one, also (and otherwise I'll build one if needed) :-)
And mr.developer can handle them all. This only solves the problem partially though: most of my projects use svn externals to pull in CSS, javascript and other resources from an external prototype. That is not supported by those zc.buildout recipes: they can only checkout a whole package. In my experience distributed SCMs add bottlenecks to development that we currently do not have in the Zope community: with both our shared svn repository and distributed SCMs everyone can branch everything, but with distributed SCMs you have to ask a maintainer to merge any changes, something everyone can do directly right now. For that reason I am still -1 on switching to git/bzr/hg/etc. Wichert.
On Sep 15, 2009, at 4:56 AM, Wichert Akkerman wrote:
In my experience distributed SCMs add bottlenecks to development that we currently do not have in the Zope community: with both our shared svn repository and distributed SCMs everyone can branch everything, but with distributed SCMs you have to ask a maintainer to merge any changes, something everyone can do directly right now.
FWIW, this is some variable degree of wrong. 1) "Everyone" cannot merge changes right now: only developers that have commit privileges can do that. That's what you meant, I expect. 2) Our current arrangement, as well as many others, can be accomplished with a DVCS. Launchpad + Bzr definitely support this. You would have a Launchpad team of committers, with managed membership; and have the official branches owned and controlled by this team. Generally, I'd be surprised to learn that Bzr/Launchpad were alone in supporting this, but they are the only ones I can vouch for. For instance, I'm almost positive that github also allows you to have multiple committers to a single branch, though I don't remember the mechanism. Gary
On 9/15/09 13:56 , Gary Poster wrote:
On Sep 15, 2009, at 4:56 AM, Wichert Akkerman wrote:
In my experience distributed SCMs add bottlenecks to development that we currently do not have in the Zope community: with both our shared svn repository and distributed SCMs everyone can branch everything, but with distributed SCMs you have to ask a maintainer to merge any changes, something everyone can do directly right now.
FWIW, this is some variable degree of wrong.
1) "Everyone" cannot merge changes right now: only developers that have commit privileges can do that. That's what you meant, I expect.
Indeed.
2) Our current arrangement, as well as many others, can be accomplished with a DVCS. Launchpad + Bzr definitely support this. You would have a Launchpad team of committers, with managed membership; and have the official branches owned and controlled by this team.
Indeed, but most people do not do that. With our current setup once you get commit privileges you immediately have access to an entire world of things. With DVCS hosting systems that people use you have would have to request access for every single package. That is cumbersome and adds a lot of delay so people don't do that and fork instead. The end result is a lot more forks, half of which will probably never be merged back or seen by others. Wichert.
On Sep 15, 2009, at 7:59 AM, Wichert Akkerman wrote:
On 9/15/09 13:56 , Gary Poster wrote:
2) Our current arrangement, as well as many others, can be accomplished with a DVCS. Launchpad + Bzr definitely support this. You would have a Launchpad team of committers, with managed membership; and have the official branches owned and controlled by this team.
Indeed, but most people do not do that. With our current setup once you get commit privileges you immediately have access to an entire world of things. With DVCS hosting systems that people use you have would have to request access for every single package. That is cumbersome and adds a lot of delay so people don't do that and fork instead. The end result is a lot more forks, half of which will probably never be merged back or seen by others.
Perhaps that is the way other systems work; again, I can only vouch for Bzr/Launchpad, and your description is incorrect for us. With Bzr/Launchpad, a single time for each project, you would designate an appropriate committer team as having commit privileges for that project. Then, for each person that should be able to commit to all of the projects, you add them to that team. This is how we have our open-source Zope-friendly lazr.* packages set up. We have a single team for committers, which has privileges for all of our lazr.* packages. When a new person should be able to commit to all of the packages in the lazr.* effort, we just add them to that team. See, for instance, the trunk of lazr.delegates: https://code.launchpad.net/~lazr-developers/lazr.delegates/trunk . You simply need to be added to lazr-developers ( https://launchpad.net/~lazr-developers ) in order to commit to this and any of the other similarly- configured lazr.* projects. Gary
On Tue, Sep 15, 2009 at 07:56:42AM -0400, Gary Poster wrote:
Generally, I'd be surprised to learn that Bzr/Launchpad were alone in supporting this, but they are the only ones I can vouch for. For instance, I'm almost positive that github also allows you to have multiple committers to a single branch, though I don't remember the mechanism.
bitbucket and github both support this, yes. (And thus presumably any repository running mercurial or git, though I don't know how to admin them.) -- Paul Winkler http://www.slinkp.com
On 2009-9-9 14:54, Hanno Schlichting wrote:
On Wed, Sep 9, 2009 at 2:40 PM, Martijn Faassen<faassen@startifact.com> wrote:
Christian Theune wrote:
However, this requires Subversion 1.5 which we are using on the server already, but I don't know whether we assume clients are 1.5 or higher.
I certainly still use a SVN 1.4.x client, being on Ubuntu 8.04 LTS (released just last year). I don't think SVN 1.5 is common enough yet to make such a move possible.
We moved all the Plone repositories (including the rather massively used collective) to Subversion 1.5.6 a while ago. So far there have been no complaints by anyone. And as Robert noted you can use a Subversion 1.4 client with a 1.5 server just fine.
I think doing the server upgrade very soon (tm) shouldn't be a problem.
Relative externals are handled on the svn client, not the svn server. Wichert. -- Wichert Akkerman <wichert@wiggy.net> It is simple to make things. http://www.wiggy.net/ It is hard to make things simple.
On Wed, Sep 9, 2009 at 8:31 AM, Christian Theune<ct@gocept.com> wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Hi,
a long-standing issue with our mirror of svn.zope.org are the absolute URLs of externals: they require the repository to be available on a given URL.
I propose to use relative URLs for externals. I guess a complete update isn't necessary, but I'd like to improve the situation and start using them from now on. Maybe we should also put a commit hook in place as a safety belt?
However, this requires Subversion 1.5 which we are using on the server already, but I don't know whether we assume clients are 1.5 or higher.
As a side effect this will also make svn/svn+ssh work in a nicer way (IMHO) as the externals will follow the protocol of what you used for checkout.
Sounds good to me. Jim -- Jim Fulton
What about upgrading server to 1.6. Subversion 1.6 has many new features.
From http://subversion.tigris.org/svn_1.6_releasenotes.html :
* Improved handling of authentication data * Repository root relative URLs * Improvements to svn:externals * Detection of tree conflicts * Filesystem storage improvements * Ctypes Python Bindings * Improved interactive conflict resolution * Sparse directory exclusion * Logging support for svnserve * New public HTTP URI syntax for examining history * Command-line client improvements * API changes, improvements, and much language bindings work * More than 65 new bug fixes, enhancements Regards, Baiju M
participants (18)
-
Andreas Jung -
Baiju M -
Benji York -
Chris Withers -
Christian Theune -
Fred Drake -
Gary Poster -
Hanno Schlichting -
Jens Vagelpohl -
Jim Fulton -
Martijn Faassen -
Paul Winkler -
Reinout van Rees -
robert rottermann -
Sebastien Douche -
Sidnei da Silva -
Tres Seaver -
Wichert Akkerman