Subversion? (Re: HEADS UP: Importing csup into base)

[Peter Wemm]

On Saturday 04 March 2006 09:11 am, Chris BeHanna wrote:
> On Mar 4, 2006, at 10:32 AM, Robert Watson wrote:
> > On Sat, 4 Mar 2006 pfgshield-freebsd at yahoo.com wrote:
> >> I wanted to avoid turning this thread into a discussion of the
> >> different VCSs but perhaps that might be healthy. Many people like
> >> perforce... I wonder if the developer community would be happy to
> >> accept a "commercial" solution.
> >
> > [...Perforce met a critical need for branched development, and
> > Subversion could not import the repo at the time...]
>
> 	And, as I recall, at the time, subversion's ability to manage
> branches in a lightweight fashion was just not there.
>
> 	How is it now?  If it still cannot compare to Perforce, then it's
> likely a non-starter.

I was also one of the svn opponents at the time.  At the time, it was 
nowhere near "there" yet.  Not even remotely.

However, I'm starting to think otherwise now.  We probably could switch 
from cvs to svn now, and without losing any functionality.

Like perforce, it is fully client/server, but it has some considerable 
advantages over perforce:

1) It has fairly good detached operation modes.  You can do logs, diffs, 
reverts, etc while detached.  It does this by keeping metadata and a 
small number of revisions cached locally.

2) It is fully open source.  In spite of Perforce's promises to build 
clients for us for any of our released platforms, they still have not 
given us a native sparc64 client, even after repeated requests.  An 
amd64 and ia64 client would be nice, but it isn't as much of a killer 
as the missing sparc64 client is.  svn would free us of this problem.

3) It has built-in http and source browser functionality.  Think cvsweb 
etc.

4) svn has its own mirror system.  we could use it if we wanted.

5) And this is the kicker..  most client metadata is kept on the client!  
This is the very reason why we cannot use perforce for freebsd.org for 
everybody.  The number of checkouts is way too large.  svn keeps most 
of this on the client, so this scales easily with more clients.

6) Finally, some icing.. its Apache/BSDish in its licensing.  Not GPL.

What svn doesn't change (relative to perforce):

1) the need to replicate the key branches to cvs.  We have such a huge 
investment in cvs, the cvsup network, etc, that we cannot just discard 
this.  No matter what vcs we use, we have to maintain this.  Like with 
perforce, we can easily replicate svn changes to a cvs tree and all 
existing users of cvsup etc will be none the wiser (except for a change 
number included in new cvs commits).

2) source tree wouldn't be held hostage.  If svn didn't work out, we 
could just have another flag day, turn off the svn->cvs replication and 
go back to using cvs as the master again.  It would be a disruption, 
but no major drama.

3) We get all the same goodies like atomic commits, change sets, cheap 
branches, etc etc that perforce gives us, just in a different way.

I'm sure there are many other pros and cons, and I know there are other 
alternatives besides svn (eg: svk, mercurial, etc etc).  I know there 
are lots and lots of quirks in svn as well.  But I've warmed up 
considerably to the idea of something like svn compared to a year or 
two ago.

The comments about svn's lack of branch merge memory make me a bit 
nervous though.  We've had brahcnes that have been incrementally merged 
hundreds of times under perforce, and the lack of remembering which 
revisions have and have not been merged would be sorely missed.

And my personal observation is that svn finally seems to be becoming the 
defacto replacement for cvs, at last.  It has picked up some very high 
profile projects - gcc for one, asterisk, etc etc.  I'm sure it will 
improve at an even faster rate now.

> 	Perforce's *huge* weakness is the way it handles its metadata (it
> wants to keep some of its databases entirely in RAM, and they get
> HUGE).  This prevents distributing the repo, and it prevents granting
> public, anonymous access to the p4 side of the world for freebsd.org
> (cripes, you'd need an E15K or an Altix cluster to have enough RAM
> and backing store for that!), but nothing else I've seen can do
> branching and merging the way Perforce can.

Yes, this is one of the key reasons why we can't use perforce for 
primary development.  Having the metadata on the server is the killer.  
We just can't do it with our load.  We've already almost killed the 
perforce server on repoman from metadata overload, and that was with a 
tiny percentage of developers using it!

-- 
Peter Wemm - peter at wemm.org; peter at FreeBSD.org; peter at yahoo-inc.com
"All of this is for nothing if we don't go to the stars" - JMS/B5