Re: [Zope-dev] Subversion externals versus mirroring
On 2009-09-11, Sebastien Douche sdou...@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 - rein...@vanrees.org - http://reinout.vanrees.org Software developer at http://www.thehealthagency.com Military engineers build missiles. Civil engineers build targets ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Subversion externals versus mirroring
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 attachment: lists.vcf___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Subversion externals versus mirroring
On 9/15/09 10:33 , Reinout van Rees wrote: On 2009-09-11, Sebastien Douchesdou...@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. ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Subversion externals versus mirroring
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 ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Subversion externals versus mirroring
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. ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Subversion externals versus mirroring
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 ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Subversion externals versus mirroring
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 ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Subversion externals versus mirroring
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 ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Subversion externals versus mirroring
On Thu, Sep 10, 2009 at 16:58, Martijn Faassen faas...@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 sdou...@gmail.com Twitter: http://bit.ly/afkrK (agile, python, open source) ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Subversion externals versus mirroring
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 ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
[Zope-dev] Subversion externals versus mirroring
-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 · c...@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- ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Subversion externals versus mirroring
On Wed, Sep 9, 2009 at 8:31 AM, Christian Theunec...@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 ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Subversion externals versus mirroring
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 ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Subversion externals versus mirroring
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 ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Subversion externals versus mirroring
On Wed, Sep 9, 2009 at 2:40 PM, Martijn Faassenfaas...@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 ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Subversion externals versus mirroring
On Wed, Sep 9, 2009 at 8:31 AM, Christian Theunec...@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 ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Subversion externals versus mirroring
Hanno Schlichting wrote: On Wed, Sep 9, 2009 at 2:40 PM, Martijn Faassenfaas...@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 ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Subversion externals versus mirroring
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 smime.p7s Description: S/MIME cryptographic signature ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Subversion externals versus mirroring
On Wed, Sep 9, 2009 at 10:35 AM, Jens Vagelpohlj...@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 ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Subversion externals versus mirroring
On Sep 9, 2009, at 15:59 , Sidnei da Silva wrote: On Wed, Sep 9, 2009 at 10:35 AM, Jens Vagelpohlj...@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 ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Subversion externals versus mirroring
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 ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Subversion externals versus mirroring
On 2009-9-9 14:54, Hanno Schlichting wrote: On Wed, Sep 9, 2009 at 2:40 PM, Martijn Faassenfaas...@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 wich...@wiggy.net It is simple to make things. http://www.wiggy.net/ It is hard to make things simple. ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Subversion externals versus mirroring
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 ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Subversion externals versus mirroring
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 · c...@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 ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Subversion externals versus mirroring
On Wed, Sep 9, 2009 at 6:40 PM, Christian Theunec...@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 ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Subversion externals versus mirroring
On Wed, Sep 9, 2009 at 12:40 PM, Christian Theunec...@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 ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Subversion externals versus mirroring
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 ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Subversion externals versus mirroring
-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 tsea...@palladion.com Palladion Software Excellence by Designhttp://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- ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Subversion externals versus mirroring
-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 Theunec...@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 · c...@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- ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Subversion merge tracking
Given the current level of consensus, I plan on precluding pre-1.5 Subversion clients from making commits some time after the middle of May 2009. I'll try add some form of warning for affected users in the next month or so. If I can't get it to work I still plan to go forward with the deprecation. -- Benji York Senior Software Engineer Zope Corporation ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
[Zope-dev] Subversion merge tracking
I'd like for us to disallow pre-1.5 Subversion clients from making commits starting one year from now (or sooner if there is consensus). The recent hardware problems for svn.zope.org had the positive outcome of precipitating an upgrade to Subversion 1.5 which has merge tracking. One of the requirements to use merge tracking is that no pre-1.5 client merge to the branch that you want to use with merge tracking. That means that as of now, anyone can use merge tracking on their projects as long as all merges are done with a mergeinfo-capable (1.5+) client. Until we ban commits from pre-1.5 clients (using a pre-commit hook), anyone who wants to use merge tracking will have to be careful with the clients they use (and watch out for rouge merges from other contributors which can be fixed-up after the fact). The Subversion book includes information about merge tracking: http://svnbook.red-bean.com/nightly/en/svn.branchmerge.basicmerging.html http://svnbook.red-bean.com/nightly/en/svn.branchmerge.advanced.html A description of the pre-1.5 client problem is at http://svnbook.red-bean.com/nightly/en/svn.branchmerge.advanced.html#svn.branchmerge.advanced.pre1.5clients -- Benji York Senior Software Engineer Zope Corporation ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Subversion merge tracking
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Nov 13, 2008, at 14:42 , Benji York wrote: I'd like for us to disallow pre-1.5 Subversion clients from making commits starting one year from now (or sooner if there is consensus). +1 jens -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.8 (Darwin) iEYEARECAAYFAkkcQx4ACgkQRAx5nvEhZLKugACfUMq7DHVTzRNdF61grqsIzFdd xqoAnRe5LpwZfh5JoD08z5Sj/SrOh0Ep =Zf2H -END PGP SIGNATURE- ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Subversion merge tracking
On Thu, Nov 13, 2008 at 1:09 PM, Jens Vagelpohl [EMAIL PROTECTED] wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Nov 13, 2008, at 14:42 , Benji York wrote: I'd like for us to disallow pre-1.5 Subversion clients from making commits starting one year from now (or sooner if there is consensus). +1 I vote for sooner, if that makes things easier. I'm already using 1.5 and I'm on Windows, so I guess the Linux users out there shouldn't have a problem getting an up-to-date package right? :) -- Sidnei da Silva Enfold Systems http://enfoldsystems.com Fax +1 832 201 8856 Office +1 713 942 2377 Ext 214 Skype zopedc ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Subversion merge tracking
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Benji York wrote: I'd like for us to disallow pre-1.5 Subversion clients from making commits starting one year from now (or sooner if there is consensus). The recent hardware problems for svn.zope.org had the positive outcome of precipitating an upgrade to Subversion 1.5 which has merge tracking. One of the requirements to use merge tracking is that no pre-1.5 client merge to the branch that you want to use with merge tracking. That means that as of now, anyone can use merge tracking on their projects as long as all merges are done with a mergeinfo-capable (1.5+) client. Until we ban commits from pre-1.5 clients (using a pre-commit hook), anyone who wants to use merge tracking will have to be careful with the clients they use (and watch out for rouge merges from other contributors which can be fixed-up after the fact). The Subversion book includes information about merge tracking: http://svnbook.red-bean.com/nightly/en/svn.branchmerge.basicmerging.html http://svnbook.red-bean.com/nightly/en/svn.branchmerge.advanced.html A description of the pre-1.5 client problem is at http://svnbook.red-bean.com/nightly/en/svn.branchmerge.advanced.html#svn.branchmerge.advanced.pre1.5clients +0, I guess: I would be more comfortable if we could measure the incidence of pre-1.5 client usage over time, and maybe even identify the committers who are using them, so that we can sent out a targeted warning message before breaking their checkouts. Tres. - -- === Tres Seaver +1 540-429-0999 [EMAIL PROTECTED] Palladion Software Excellence by Designhttp://palladion.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFJHFWo+gerLs4ltQ4RAlDWAJ4mhFz6683K5eLs3T061ejSCaiIQACghWmn OQjtYqIrO3TXnn5SsrjhrL4= =Bncy -END PGP SIGNATURE- ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Subversion merge tracking
On 13.11.2008 14:42 Uhr, Benji York wrote: I'd like for us to disallow pre-1.5 Subversion clients from making commits starting one year from now (or sooner if there is consensus). +1 - six months should be enough for the transition. Andreas begin:vcard fn:Andreas Jung n:Jung;Andreas org:ZOPYX Ltd. Co. KG adr;quoted-printable:;;Charlottenstr. 37/1;T=C3=BCbingen;;72070;Germany email;internet:[EMAIL PROTECTED] title:CEO tel;work:+49-7071-793376 tel;fax:+49-7071-7936840 tel;home:+49-7071-793257 x-mozilla-html:FALSE url:www.zopyx.com version:2.1 end:vcard ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Subversion merge tracking
On Thu, Nov 13, 2008 at 2:28 PM, Tres Seaver [EMAIL PROTECTED] wrote: +0, I guess: I would be more comfortable if we could measure the incidence of pre-1.5 client usage over time, and maybe even identify the committers who are using them, so that we can sent out a targeted warning message before breaking their checkouts. Checkouts are not a problem, only checkins. -- Sidnei da Silva Enfold Systems http://enfoldsystems.com Fax +1 832 201 8856 Office +1 713 942 2377 Ext 214 Skype zopedc ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Subversion merge tracking
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Sidnei da Silva wrote: On Thu, Nov 13, 2008 at 2:28 PM, Tres Seaver [EMAIL PROTECTED] wrote: +0, I guess: I would be more comfortable if we could measure the incidence of pre-1.5 client usage over time, and maybe even identify the committers who are using them, so that we can sent out a targeted warning message before breaking their checkouts. Checkouts are not a problem, only checkins. I'm talking about users who have *existing* checkouts on a pre-1.5 machine. If they are make a commits from there, during the deprecation period, we should collect that information, so that we can notify them before breaking their ability to make further commits. Tres. - -- === Tres Seaver +1 540-429-0999 [EMAIL PROTECTED] Palladion Software Excellence by Designhttp://palladion.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFJHFoi+gerLs4ltQ4RAkWcAJ97an0p0FjwGG2SuMLjIxVNw0FMBwCgsgOM cQvNBSRv2YPTIlVIBSyIihk= =8+my -END PGP SIGNATURE- ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
[Zope-dev] Subversion upgrade this weekend
I plan to update our subversion server to version 1.4 this weekend. I'll take our repositories offline for a little while while I do this. I don't know exactly when I will do this. Hopefully, it will happen so fast that no one will notice. :) Jim -- Jim Fulton mailto:[EMAIL PROTECTED]Python Powered! CTO (540) 361-1714 http://www.python.org Zope Corporationhttp://www.zope.com http://www.zope.org ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Subversion
Lennart Regebro wrote: Well... Non-issue it is not. But it makes it much less of an issue. It would still be nice to have server-side configurations of defalts, though. Yeah, but from what Jim said, that's something the svn guys are aiming to do. I guess the best thing would be to hassle/help on the subversion project to speed this up... cheers, Chris -- Simplistix - Content Management, Zope Python Consulting - http://www.simplistix.co.uk ___ Zope-Dev maillist - [EMAIL PROTECTED] http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [reportlab-users] Re: [Zope-dev] Subversion
(cc'ing this to zope-dev in case this is of interest to them too) Robin Becker wrote: Chris Withers wrote: Tim Peters wrote: . Cool :-) Glad to find this one is a non-issue! Chris I hacked cvs2svn.py and seem to be getting it to look up the b tag in place of the mime-types stuff which is also possible. -- Simplistix - Content Management, Zope Python Consulting - http://www.simplistix.co.uk ___ Zope-Dev maillist - [EMAIL PROTECTED] http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Subversion
Tim Peters wrote: svn's story is much better (perfect, in fact) when forgetting to add eol-style: regardless of which kind of platform did the commit, the property can be added after the fact by anyone, and svn will automatically repair working copies on all platforms. Because (most) svn properties are versioned, adding eol-style is enough to convince svn that pre-eol-style copies are out of date. Nobody even needs to bother running dos2unix or unix2dos; just adding the property is enough (and when the person who adds the property commits the change, svn fiddles the line ends on their working copy (if needed) by magic too). Cool :-) Glad to find this one is a non-issue! Chris -- Simplistix - Content Management, Zope Python Consulting - http://www.simplistix.co.uk ___ Zope-Dev maillist - [EMAIL PROTECTED] http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Subversion
Chris Withers wrote: Tim Peters wrote: svn's story is much better (perfect, in fact) when forgetting to add eol-style: regardless of which kind of platform did the commit, the property can be added after the fact by anyone, and svn will automatically repair working copies on all platforms. Because (most) svn properties are versioned, adding eol-style is enough to convince svn that pre-eol-style copies are out of date. Nobody even needs to bother running dos2unix or unix2dos; just adding the property is enough (and when the person who adds the property commits the change, svn fiddles the line ends on their working copy (if needed) by magic too). Cool :-) Glad to find this one is a non-issue! Well... Non-issue it is not. But it makes it much less of an issue. It would still be nice to have server-side configurations of defalts, though. ___ Zope-Dev maillist - [EMAIL PROTECTED] http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Subversion
Hi Tim, Tim Peters wrote: There's a svn property you can set on a higher level folder in the repository that can control a mapping for file extensions to this property, IIRC. I am hazy on it but I know it's possible. If so, it's not documented. Perhaps you're thinking of the svn:ignore property? Damn, that's it :-S Is it worth asking on the SVN lists how hard this would be to implement? I mean, we have the svn:ignore property, and we have the svn:eol-style property, what we want is a combination of those two, how hard can it be? 0.5 wink glob-based eol-style property addition can be specified in your svn config file's auto-props section, like [auto-props] *.c = svn:eol-style=native *.png = svn:mime-type=image/png but there's no provision for sharing such personal settings with other people (the config file belongs to the user, not to the repository). Yep, the above is what I do. I suppose it's still one step up from CVS where you have to specify the binary-ness of each file you upload rather than being able to put a mapping i na config file... cheers, Chris -- Simplistix - Content Management, Zope Python Consulting - http://www.simplistix.co.uk ___ Zope-Dev maillist - [EMAIL PROTECTED] http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Subversion
Chris Withers wrote: I suppose it's still one step up from CVS where you have to specify the binary-ness of each file you upload rather than being able to put a mapping i na config file... CVSROOT/cvswrappers ___ Zope-Dev maillist - [EMAIL PROTECTED] http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
RE: [Zope-dev] Subversion
[Chris Withers] ... Is it worth asking on the SVN lists how hard this would be to implement? I mean, we have the svn:ignore property, and we have the svn:eol-style property, what we want is a combination of those two, how hard can it be? 0.5 wink I don't think we want a combination of the two: like .cvsignore, svn:ignore only applies to the contents of a single directory (the one on which svn:ignore is set). We'd really like something global (e.g., .py files are text files throughout all of Zope's code). The svn config file is global (or global enough wink). Jim and I bugged the Subversion folks last week. Ben Collins-Sussman replied (in part): http://www.contactor.se/~dast/svnusers/archive-2004-04/1373.shtml At this point, the user community has made it absolutely clear that we really need a repository-side configuration which somehow 'broadcasts' runtime configuration options to clients, such as auto-props. Yes, it's burdensome to force every client to hand- maintain auto-props. For now, you'll need to choose between that burden, or the burden of occasionally fixing a mistake when someone forgets to activate native eol style. There's another difference between cvs and svn here: if you forget to mark a file as binary in cvs, it can be hard to recover from. If a Windows user checked it in, the file in the repository may be corrupt. If a Linux user checked it in, and a Windows user grabbed it before -kb was added, the Windows copy may be corrupt, and cvs won't repair that by magic when -kb is added (a cvs update doesn't consider the Windows working copy to be out of date). svn's story is much better (perfect, in fact) when forgetting to add eol-style: regardless of which kind of platform did the commit, the property can be added after the fact by anyone, and svn will automatically repair working copies on all platforms. Because (most) svn properties are versioned, adding eol-style is enough to convince svn that pre-eol-style copies are out of date. Nobody even needs to bother running dos2unix or unix2dos; just adding the property is enough (and when the person who adds the property commits the change, svn fiddles the line ends on their working copy (if needed) by magic too). ___ Zope-Dev maillist - [EMAIL PROTECTED] http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
[Zope-dev] Subversion
(cross-posted to zope-dev too, seems relevent there ;-) Marius Gedminas wrote: BTW the Zope subversion conversion hit a snag due to line ending style on Windows. Apparently cvs2svn does not add the required svn:eol-style properties for text files, cvs2svn is a python script, surely you guys can hack a little? ;-) and they have Unix line endings even when checked out on Windows systems. Also, it is unclear if newly added text files on Windows will be properly converted to Unix line endings in the repository. There's a svn property you can set on a higher level folder in the repository that can control a mapping for file extensions to this property, IIRC. I am hazy on it but I know it's possible. cheers, Chris -- Simplistix - Content Management, Zope Python Consulting - http://www.simplistix.co.uk ___ Zope-Dev maillist - [EMAIL PROTECTED] http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
RE: [Zope-dev] Subversion
[Chris Withers] ... There's a svn property you can set on a higher level folder in the repository that can control a mapping for file extensions to this property, IIRC. I am hazy on it but I know it's possible. If so, it's not documented. Perhaps you're thinking of the svn:ignore property? glob-based eol-style property addition can be specified in your svn config file's auto-props section, like [auto-props] *.c = svn:eol-style=native *.png = svn:mime-type=image/png but there's no provision for sharing such personal settings with other people (the config file belongs to the user, not to the repository). ___ Zope-Dev maillist - [EMAIL PROTECTED] http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
[Zope-dev] Subversion repository layout
The standard subversion repository layout is by project: proj1 /trunk /branches /br1 /br2 ... /tags /tag1 /tag2 ... proj2 /trunk /branches /br1 /br2 ... /tags /tag1 /tag2 ... ... With this layout, when you want to checkout the main development branch (aka head) of ZODB, you do: svn co svn+ssh://svn.zope.org/repos/ZODB/trunk ZODB That is, you need to include /trunk at the end and provide ZODB as the name of the output directory so as not to get a directory named trunk. If you forget the /trunk, you'll get a checkout that includes copies of all of the various tags and branches, which could be huge. I suggest, instead to use the following layout: proj1 proj2 tags /proj1 /tag1 /tag2 ... /proj2 /tag1 /tag2 ... branches /proj1 /br1 /br2 ... /proj2 /br1 /br2 ... With this layout, when you want to checkout the main development branch (aka head) of ZODB, you do: svn co svn+ssh://svn.zope.org/repos/ZODB which seems cleaner and less error prone. The only disadvantage I see in this layout is that we couldn't have projects named tags or branches, but I could live with that. Alternatively, we could have a top-level trunk directory: trunk /proj1 /proj2 tags /proj1 /tag1 /tag2 ... /proj2 /tag1 /tag2 ... branches /proj1 /br1 /br2 ... /proj2 /br1 /br2 ... But that would require inclusion of a /trunk dead chicken in checkouts: svn co svn+ssh://svn.zope.org/repos/trunk/ZODB which seems unnecessary to me. Thoughts? Jim -- Jim Fulton mailto:[EMAIL PROTECTED] Python Powered! CTO (540) 361-1714http://www.python.org Zope Corporation http://www.zope.com http://www.zope.org ___ Zope-Dev maillist - [EMAIL PROTECTED] http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
