I also said inevitable :) For the reasons Rasmus mentions it makes very much sense for us to move to SVN. Over the years, as the PHP project has grown, we have increasingly felt the shortcomings of CVS. In addition, there are likely to be additional ways SVN can benefit our dev process. At the end of the day, the main pain will be felt by the people who actually migrate the data and supporting systems. For the end user it won't take a lot to adapt. Also, we may loose some history even with manual intervention, but we can/should keep the old CVS repository around (maybe in museum.php.net) so that we will always have access to the past... In any case we will hopefully be able to save the majority of the metadata.
As we expect many more years for PHP we should make sure that the train we're riding has momentum and can help us continue to scale our dev process. I think SVN is the right train to hop onto. Andi > -----Original Message----- > From: Rasmus Lerdorf [mailto:[EMAIL PROTECTED] > Sent: Wednesday, May 30, 2007 7:57 AM > To: [EMAIL PROTECTED] > Cc: PHP Internals List > Subject: Re: [PHP-DEV] better changeset tracking > > Jani Taskinen wrote: > > On Wed, 2007-05-30 at 01:29 -0700, Rasmus Lerdorf wrote: > >> Well, the problem is that if the work involved to do this > is in any > >> way CVS-specific, it will be throw-away work once we move > away from > >> CVS, which is inevitable. What we don't know at this point is the > >> lifespan of CVS. I'm unmotivated to do anything with SVN with the > >> major 1.5 > > > > You keep repeating "inevitable", but exactly what is the > "inevitable" > > here? AFAIK, CVS works fine: don't fix if it isn't broken! > > I'd like to here the (real) reasons why the switch would be > beneficial > > for project like PHP. > > I keep repeating? I have said that exactly once. > > The problem with CVS is that nobody is working on improving > it. There are a lot of features in modern source control > systems that we will never see in CVS. Not that subversion > has them yet either, but with version 1.5 they are moving in > the right direction. > > Some of the things that would directly benefit the project: > > - Easier to handle changesets > this can be hacked onto CVS, but nobody has done this yet for > cvs.php.net > > - Sparse checkouts (1.5) > Ever try checking out phpweb and get stuck waiting for all the > distribution tarballs to download or having your disk fill up > because of it? > > - Better performance > > - Atomic commits > > - Merge tracking (1.5) > Andi mentioned that our process wouldn't benefit from this, but > I think that is a case of our process being set up to match the > limitation of the tool and not necessarily because it is the > best way to do things. With merge tracking you get repeated > merges and the ability to cherry pick changes from one branch > without messing up the previous or subsequent merges. > > - svn blame, status and diff --summarize are all quite handy > > - It would be nice to have real rename and move support to avoid the > manual repository hacks > > - Better integration with external tools > > The big negatives are of course: > > - We lose real tagging > > - We will lose commit history on some files > > - Our less technical users will be confused for a while > > - The development process will be affected > > -Rasmus > > -- > PHP Internals - PHP Runtime Development Mailing List To > unsubscribe, visit: http://www.php.net/unsub.php > > -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
