Re: Moving to an alternate VCS

[Daniel Berlin <dberlin at dberlin dot org>]

On Mon, 2005-02-07 at 20:41 -0500, Walter Landry wrote:
> 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.
> 

1. tagging is slow
2. branching gets slow (IE checkouts from  branches) for long lived
branches, 
3. merging into branches is more of a pain in the ass than it should be
(we should simply be able to say "bring in changes between global
revision number x and global revision number y, into this tree, instead
of trying to specify it on a per-file basis)
4, Everything else is more or less sugar (the fact that it allows
offline diffs, etc)


> 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.

Sorry, we don't plan on moving to a completely distributed vcs right
now.
This is intentional.

As for creation of experimental throw-away branches, the idea that you
need a distributed vcs for that to work is just BS :).  We have had 796
branches (according to the repo statistics) in the gcc cvs repository,
over the course of 7 years.
People are free to create branches, and people do create branches for
significant work. Nothing thus far about CVS has discouraged them, but
after a few months of merging, they get tired of tag, wait, diff +
merge, wait, commit.  Not the resolving of conflicts so much as the
waiting parts. Also, any branch for more significant work becomes slow
after you perform a large number of merges onto it.

We aren't looking to change the model entirely, just make life somewhat
easier by making things faster and easier (merge, commit).

I believe that claims that we *should* change the development model to
be completely distributed will continue to fall on deaf ears while the
current development model works fine for us (the tools are getting a bit
rusty, hence the reason for exploring a replacement).  I don't speak for
everyone of course, however, i believe this observation to be correct
after watching the reactions for many years to these suggestions.

Maybe this will change some day.
> 
> >   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.
We don't want a distributed system right now.
We want a central server.
We don't want anything that forces naming conventions on us.
We don't want anything that will force anything more than a minor
learning curve
In short, we don't really want to heavily change the existing workflow,
or the way business is done. Just make it faster, and moderately easier.

Yes, i'm aware ArX solves some of these problems with regard to arch.
However, it just doesn't seem to have the community, or the support,
that svn does.
Maybe it will in a few years.

> <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.

Well, some (admittedly, they are "farther out there" than most, so to
speak) don't have bright futures at this point.
Some are one man shows that when the developer gets bored, it will die.

> 
> > 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.
If there is no real gain, why should they move?
Their is also an issue of productivity vs learning curve. At this point,
most gcc developers are *not* willing to trade off anything more than a
small amount of learning curve for any productivity gain.  Maybe it
won't be this way in the future, maybe it will.

> 
> 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.

Except it's much easier to make an SVN->whatever converter.
You can make one using only the scripting bindings. It would probably
take you roughly a week to have it fully working.
Whereas you can't really reuse the code from rcs or cvs for parsing rcs
files, everyone writes their own parsers. And their have been multiple
extensions to the RCS format (CVSNT allows tihngs that CVS doesn't,
etc).

> 
> > 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?
> 

log_accum, various auto-checkout and permission setting scripts.
Nothing too hard, but work.


> > 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 can't answer this one, because i don't remember if we have any native
windows people. We have native osx people.
However, no offense, but i'm a bit skeptical of your responses above. It
took at least 6 months to a year for multiple people to come up with
released, stable versions of the replacement tools for the above.


> 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.
Again, our current goals are more in line with what Subversion purports
to be: a better cvs.

The reality is it may turn out that svn doesn't offer enough gain for
us.  That's why we are testing it :)