Re: Moving to an alternate VCS

[Walter Landry <wlandry at ucsd dot edu>]

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

I am not asking you to move to a _completely_ distributed model.
There will still be a central server that only allows commits from
authorized people.  You can back it up, mirror it, maintain an audit
trail, etc.  If you like, you can ignore all of the extra features ;)

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

I am not talking about branches for significant work.  I am talking
about insignificant stuff.  Stuff you hacked while in a plane or on a
mountain.  Version control is still useful then.  Maybe you never
travel and always work on your net-connected machine, but I can't
believe that all of the gcc hackers are like that.

I am also talking about branches for people who don't have write
access.  Maybe you don't care about making it easy for outsiders to
hack on the code, but I feel that is your loss.

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

That sounds pretty discouraging.

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

You can close your eyes and pretend it isn't there.

> We want a central server.

You've got it.

> We don't want anything that forces naming conventions on us.

You've got it.

> We don't want anything that will force anything more than a minor
> learning curve

Not all distributed systems have to be as complex as tla.  Darcs, for
example, is supposed to be extremely easy to use.  I will let others
be the judge for ArX.

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

No arguments there.  But you did say that this will take some time.
In any case, I do have dreams ;)

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

OS X already works.

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

There are already multiple people who have implemented equivalents for
cvsweb/viewcvs for tla.  Converting them to use ArX is not hard.  I
have done it for other projects (cvs converters, patch queue manager).
I know how to borrow ;) [1]

As for the other things (bugzilla integration, post-commit scripts), I
would have to see them to make a definitive answer.  Where can I find
them?

Or is there something else that you are thinking of?

Cheers,
Walter Landry
wlandry@ucsd.edu

[1] http://superbeast.ucsd.edu/~landry/ArX/ArX-2.2.0/src/arx/utility_functions/xdelta/xdelta.cpp