Where is FreeBSD going?

[Doug Rabson]

On Wed, 2004-01-07 at 20:19, Robert Watson wrote:
> On Wed, 7 Jan 2004, Roman Neuhauser wrote:
> 
> >     [1] has core@ considered subversion (devel/subversion)?
> 
> Everyone has their eyes wide open looking for a revision control
> alternative, but last time it was discussed in detail (a few months ago?)
> it seemed there still wasn't a viable alternative.  On the src tree side,
> FreeBSD committers are making extensive use of a Perforce repository
> (which supports lightweight branching, etc, etc), but there's a strong
> desire to maintain the base system on a purely open source revision
> control system, and migrating your data is no lightweight proposition. 
> Likewise, you really want to trust your data only to tried and true
> solutions, I think -- we want to build an OS, not a version control
> system, if at all possible :-).  Subversion seems to be the current
> "favorite" to keep an eye on, but the public release seemed not to have
> realized the promise of the design (i.e., no three-way merges, etc).  You
> can peruse the FreeBSD Perforce repository via the web using
> http://perforce.FreeBSD.org/ -- it contains a lot of personal and small
> project sandboxes that might be of interest. For example, we do all the
> primary TrustedBSD development in Perforce before merging it to the main
> CVS repository. 

I've been re-evaluating the current subversion over the last couple of
weeks and its holding up pretty well so far. It still misses the
repeated merge thing that p4 does so well but in practice, merging does
seem to be a lot easier than with CVS due to the repository-wide
revision numbering system - that makes it easy to remember when your
last merge happened so that you don't merge a change twice.

The three main showstoppers for moving FreeBSD to subversion would be:

1. A replacement for cvsup. Probably quite doable using svnadmin
   dump and load.
2. Support for $FreeBSD$ - user-specified keywords are not supported
   and won't be until after svn-1.0 by the looks of things.
3. Converting the repository. This is a tricky one - I tried the
   current version of the migration scripts and they barfed and died
   pretty quickly. Still, I'm pretty sure that the svn developers
   are planning to fix most of those problems. From mailing-list
   archives, it appears that they are using our cvs tree as test
   material for the migration scripts.