Curious about SCM choice

[John Baldwin]

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