Date: Sun, 5 Mar 2006 19:30:25 -0800 From: Peter Wemm <peter@wemm.org> To: freebsd-arch@freebsd.org Cc: Chris BeHanna <chris@behanna.org> Subject: Re: Subversion? (Re: HEADS UP: Importing csup into base) Message-ID: <200603051930.25957.peter@wemm.org> In-Reply-To: <BA422F74-E7F9-4F53-9A88-B89E2255FF00@behanna.org> References: <20060304141957.14716.qmail@web32705.mail.mud.yahoo.com> <20060304152433.W61086@fledge.watson.org> <BA422F74-E7F9-4F53-9A88-B89E2255FF00@behanna.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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@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@wemm.org; peter@FreeBSD.org; peter@yahoo-inc.com "All of this is for nothing if we don't go to the stars" - JMS/B5
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200603051930.25957.peter>