Date: Fri, 27 Jun 2008 02:14:46 -0400 From: John Baldwin <jhb@freebsd.org> To: freebsd-arch@freebsd.org Cc: Milo Hyson <milo@cyberlifelabs.com>, Doug Barton <dougb@freebsd.org> Subject: Re: Curious about SCM choice Message-ID: <200806270214.46861.jhb@freebsd.org> In-Reply-To: <48647AAD.5040909@FreeBSD.org> References: <E2C84A13-15E7-4BFE-B44F-A4C27966188C@cyberlifelabs.com> <48647AAD.5040909@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Friday 27 June 2008 01:29:17 am Doug Barton wrote: > Milo Hyson wrote: > > I apologize in advance if I have the wrong list for this, but it didn't > > really look like anywhere else was more appropriate. > > > > I'm curious about the reasons for FreeBSD adopting Subversion over the > > other candidate systems. I've read the pages discussing the pros and > > cons, but haven't found anything discussing the ultimate deciding > > factors. I ask not because I disagree with the decision, but because my > > company is currently facing a similar situation. We currently use > > Subversion but there is some interest in other tools. Understanding what > > "tipped the scales" as it were could prove valuable in our own decision > > making. > > I am NOT the expert on this, but I'll try to give you something to chew > on (in no particular order) until someone smarter speaks up. :) > > 1. It's better to start collecting meta-data (change sets, merge info, > etc.) sooner than later. > 2. Of the systems available at this point, subversion is the easiest to > export _from_. Which is to say, if we decide to use something else later > on down the road it will be easier to migrate the repository from > subversion to $NEWTHING. It's also possible to use frontends like git > and Hg with subversion now, so people who really like those systems can > have a comfortable environment to work in. > 3. Subversion is close enough to cvs to give old farts like me less > stress over the change. > 4. Most of the other VCS' focus heavily on the idea of "distributed" > operation, which doesn't really fit our development model. Another factor is that in SVN keyword expansion ($Id$ and the like) still uses monotonically increasing numbers. Thus, you can run 'ident' on a file and you can tell if it is newer or older than another version of the file. AFAIK, git and hg both use hashes to represent different versions of a file, and you can't just look at two different MD5 hashes and know which one is newer or older. You have to actually have a repository lying around that you can connect to and query. This is more an issue of user ease-of-use than developer ease of use. Think of the case of security advisories (this was fixed in version X on the RELENG_foo branch). It's easier to see if your latest build has version X when you have version numbers than if you deal with hashes. Another requirement that FreeBSD has is the ability to be able to obliterate portions of the tree (e.g. someone accidentally commits something that they shouldn't have due to a misunderstanding, etc.). CVS is the easiest here as you can just rm the foo,v files and cvsup will cope. :) SVN is somewhat doable (my understanding is that one does a dump piped through a filter to remove the undesirables piped to restore). I'm not sure what the level of obliterate support is in hg/git. I know at one point neither supported it, but I thought I had heard that at least one was working on adding it. git is also designed to handle smaller repositories, so the preferred model for using git on a large codebase is to split your code base up into many smaller repositories. At least that is my understanding. For FreeBSD that didn't really fit our development model as one of our traditional strengths/differentiators has been a unified tree that contains a full OS. -- John Baldwin
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200806270214.46861.jhb>