Re: Re: CVS Access Method

Johannes Schlüter wrote: > On Sat, 2007-02-03 at 11:02 +0100, Arnaud Limbourg wrote: >> Branching and tagging is better in svn. One could mention atomic commits >> as well :) > > A copy is neither a branch nor a tag :-) > > Just a few of the tagging/branching issues I see: > > - To diff your current working copy with a given tag you can do > cvs diff -r TAGNAME file.ext > with svn you need the full URL. > svn diff http://svn.php.net/pear/package/file.ext file.ext > > - You need to have additional work to prevent commiting on a banch. > With CVS you can only commit to HEAD and branches, not to a > RELEASE_1_0 tag. > > Not to forget the other issues svn has - while CVS has issues I don't > think php.net should change to svn just because everybody else does > (while I, for myself, don't care too much about what PEAR does) :-) Hi, This is all moot until someone steps forward with hardware. The SVN book has example pre-commit scripts that can be used to prevent committing to a tag. This requires slightly more setup, but with a small project like pear2, I don't see an issue. Let me be clear here: there is absolutely NO discussion on the table regarding anything outside of cvs.php.net/pear or cvs.php.net/pear-core. We are not going to suggest changes to php-src/ phpdoc/ etc. Anything discussed on pear-dev only applies to PEAR. I have no interest in talking endlessly about something we do not control. Some advantages that SVN has which would solve several problems we've had: - you can specify things like line endings (something we use replacement tasks for in package.xml 2.0) - you can choose not to do automatic tag replacements for things like $Id$ - diffing and making patches is possible offline - linking commits to bug fixes/feature enhancements is easy to do - scripts for karma are just as easy as CVS disadvantages: - you can choose not to do automatic tag replacements for things like $Id$, which means it must be manually enabled for each file. - tags are not treated differently from branches, and must be protected with pre-commit scripts. The first is actually quite annoying, as svn properties are confusing, and so we would need an admin, or at the very least some special svn-specific PEAR commands for setting up a repository. Let's not get ahead of ourselves. Who would like to volunteer hardware? Thanks, Greg