X.Org Foundation - Release Call - 3rd May 2004

[Eric Anholt]

On Wed, 2004-05-12 at 06:44, Egbert Eich wrote:
> Daniel Stone writes:
>  > From one half of the 'complainers', this would be a step backwards.
>  > Subversion is really CVS dressed up with a nicer method of branching,
>  > proper copies, et al, and has its own reliability/scalability issues,
>  > not to mention the not-infrequent protocol/on-disk format changes.
>  > 
>  > I was personally gunning for Arch. Full disconnected operation, proper
>  > changesets and GnuPG signing of them, crazy branching and crazier
>  > merging (in a good way). It's really the only SCM system that scales,
>  > and it's fantastic for people working on completely unrelated things in
>  > branches, or people working offline, or whatever.
>  > 
> 
> CVS is a tool that is widely deployed. It is well known and people know
> how to work with it. It is know to be stable (more or less). I don't
> say it is perfect - and some features are definitely missing.
> 
> If we are going to replace it we make the burdeon on people who want
> to get involved even higher. 
> On the one hand you want to get rid of Imake with the argument that
> it is not widely know yet you suggest to exchange the revision control
> system with something that is not well known.
> 
> Furthermore any proposed revision control system must be compatible
> across versions. This must be guaranteed before we can even start
> considering it. This is essential in a distributed development 
> environment.
> 
> Egbert.

(picking a random message to post my SCM response on)

FreeBSD has had many flamewars over the replacing-CVS issue.  Everyone
agreed that CVS sucks and want to replace it, but every alternative had
major downsides.  But there was still a need for good branching support
for developers who were doing major projects (i.e. working on major
cross-subsystem projects that would take long periods of time, while
those subsystems continued changing).  What happened was that perforce
was set up on a freebsd.org machine with hourly imports from HEAD, which
people are free to use as their development sandboxes.  It makes it
easier for developers in ways (hmm, what if I take locking work from
this branch and add it to what I was working on?), but also removed
problems of people getting hit by busses or real life and the project
losing all their accumulated work.

I'm not advocating p4 in any way.  I've used it a bit to handle merging
the DRM to our CVS, but it drives me up the wall in its own ways and
licensing is problematic.  I haven't tried any other SCMs yet.  But if
there is a strong desire by developers to have development branches that
can get handled well, it may be a good idea to do it that way --
$ALTERNATIVE_SCM for WIP work where atomic commits and branching are
really handy, but merge everything intended for production to CVS.

This path of course doesn't solve the problem in general (still no
atomic commits on the mainline development, for example), but I feel
like this solution makes $ALTERNATIVE_SCM totally optional, doesn't lock
us out of future decisions on a primary SCM, and has been pretty
effective in killing off SCM flamewars until a clear winner comes around
somehow.

-- 
Eric Anholt                                eta at lclark.edu          
http://people.freebsd.org/~anholt/         anholt at FreeBSD.org