Moving to an alternate VCS

[Walter Landry <wlandry at ucsd dot edu>]

Daniel Berlin wrote:
> While sitting here waiting 3 hours for the tagging operation to
> complete on the server, for probably the 20th time in 3 months, i've
> had a lot of time to explore our opportunities to move to a version
> control system that doesn't suck[1].

So would you say that the principal reason you want to move is because
tagging is slow?  There are many reasons to switch, and I just want to
make sure that I understand what is driving this.

> In fact, i'm pretty sure at this point that people with branches
> spend more time waiting for the tagging, merging, and committing, to
> complete, than they do resolving any conflicts that come up.
> 
> I believe we are quickly approaching a point where our relatively
> new development model of using branches for things is starting to
> absolutely kill cvs performance.  I don't believe changing
> development models is the answer, this one works nicely, except for
> the wasted time waiting on the VCS :).
>
> Therefore, I believe we should seriously start considering and
> talking about a migration path to a version control system we can
> work with in the next year.  For the sole purposes of keeping such a
> discussion under control (so to speak), i posit that the only sane
> choice we have to make such a migration in the next year or so, is
> Subversion.
>
> My reasons are simple:

I agree with most of the observations, and will only comment on the
reasons I have issues with.

<snip>
>   c. Subversion would alleviate most of the heavy pain of branching
>   and maintaining branches.

This is not so clear.  It will certainly make it easier than it is
now, but subversion requires everyone to have their branch on the main
server.  It discourages experimental, throw-away branches because you
are cluttering up the namespace for everyone.

>   d. It forces no real things on us that we don't really want to
>   deal with right now, as some other contenders do.

You will have to be more clear here.

<snip>
> 3. It's future is bright.  Things we may wish for that it doesn't support 
> (full merge history), have 3rd party tools to significantly help 
> with (svnmerge), and are planned as future enhancements (IE on the 
> roadmap).

You could say this about most of the alternatives.  Everyone has plans
to become greater.  What _is_ significant is that Subversion is actively
developed and has a large community.

> 4. Moving from a changeset based system to another changeset based system 
> at some point in the future (IE when monotone has fully matured, or 
> whatever) seems to me a much less difficult move than moving from cvs to 
> anything.

I would not say that this is true.  Once you have moved from something
terrible to something half-decent, it is much harder to get people to
move on to something better.  There simply is not enough pain.

Even at a technical level, converting a repo from svn to anything else
would not be easier.  Almost everyone already has a CVS -> (whatever)
converter, but not a SVN -> (whatever) converter.

> Also, in order to keep the discussion under control, anyone who feels the 
> need to disagree with the above will be signed up to do the work 

I have been considering putting up a demo ArX [1] repository for gcc
for a little while.  This just gives me another excuse to do so.

> of moving all of our post-commit scripts to the new system,

What are they?

> making all of our various tools (bugzilla integration,

Should not be hard.

> cvsweb, viewcvs,

Hmm.  This has been on my todo for quite a while.  Some work, but
quite manageable.

> mirroring)

Should not be hard.

> work with it, making ssh based authentication and serving viable

No problem.

> (or an effective replacement for it viable), as well as making sure
> it works on all the platforms our developers use.

That is a tricky one.  Is there a definitive list of such platforms?
In particular, is native Windows support (not cygwin) required?

> I'm willing to put forth the effort to attempt the above (with help, of 
> course), so you should be to if you are going to advocate something else.
> 
> I'm not even close to suggesting we move now, or anytime in the near 
> future.  But i believe we need to at least start to have a plan in place 
> to migrate at some definite point in the future, and we should be starting 
> this process now.
> 
> P.S. My tagging still hasn't finished, and i started this message 2 hours 
> ago. Whee!
> 
> [1] Though this isn't the sum total of my time spent thinking
> about it, or even working with the alternatives. I've actually contributed
> significant patches to cvs2svn and other parts of subversion since a few 
> years ago, and to monotone.

As a developer of one of these alternatives, I do not think that a
move to Subversion would necessarily be a bad idea.  There are some
things that Subversion does better than anything else.  I just don't
think it is necessarily the best idea.

Cheers,
Walter Landry
wlandry@ucsd.edu

[1] http://www.nongnu.org/arx/