Re: [boost] Re: Moving from CVS to Subversion?

From: Walter Landry (wlandry_at_[hidden])
Date: 2005-02-05 11:39:28

David Abrahams <dave_at_[hidden]> wrote:
> Walter Landry <wlandry_at_[hidden]> writes:
> 
> > I think that svn is the logical choice if you want to stay with a
> > centralized model.  I just don't think that the centralized model is
> > the best way.  
> 
> If there's no central repository, how do you know what the "real"
> state of the codebase is?  How does it get backed up?  How does
> decentralization interact with automated testing?

This is explained more fully elsewhere [1] [2], but one way to do it
is to have a centralized repository that people send merge requests
to.  So Boost might have a Grand Pooh-bah (GPB) who controls this
repository.  Developers branch off of this repository and, when they
are done, ask the GPB to merge in their changes.  If you trust your
developers as much as you trust them now, you can make the GPB a robot
that automatically merges in their changes.  This is also called a
patch queue, and there is one that exists for tla and ArX.  However,
it is pretty easy to retrofit it for other distributed version control
systems.

> > The distributed alternatives all have issues, but you have to weigh
> > that against the problems with a centralized model.  Obviously, the
> > centralized model is not a deal-breaker, because Boost has been
> > surviving with CVS.  But it is important to understand what kind of
> > problems you will have with any centralized model.
> >
> > For example, from a different email you wrote
> >
> >   I don't have much to say other than to say that some of us spend a
> >   lot of time waiting for CVS,
> >
> > What kind of operations are you doing that require waiting?  
> 
> Update, for one.  And for that one substantial churn happens on the
> local machine before any bits move across the network.

Interesting.  Subversion doesn't seem to be faster for that operation
[3] [4].  However, there are claims that you don't have to do it as often
[5].  YMMV.  In general, I would say that there are lots of good
reasons to switch away from CVS to something else, but performance is
not one of them.

> The others usually require some mildly annoying wait, too, but that's
> the biggie.
> 
> > Some operations in distributed systems do not require talking to the
> > central server at all.  Even "update" will differ because the work
> > patterns are different.  
> 
> Details?

With a distributed system, you can do more work away from the central
repository.  So you may end up with fewer, larger patches.  That
impacts the speed of updates.  At least, that is the theory.

Also, with the better merge tools in the distributed systems, you
don't have to run update all the time.

> > In any case, getting a new host (OSL) may solve some of this.
> 
> Maybe, but as I've been saying, the problems with update are
> substantially due to the way CVS works.
> 
> >   there are constant stale locks,
> >
> > This problem mostly goes away with distributed systems.
> 
> And completely goes away with SVN.

It can never completely go away.  If you have multiple people who can
modify a repository, you have to have locks.  Then things can happen
(network goes away) that prevent you from freeing the lock.

However, you can do a number of things to minimize how long you have
to hold a lock, and how easy it is to remove a stale lock.  For modern
systems, it really boils down to a QOI issue.  My impression of svn is
that has improved a great deal since their early releases.

Finally, I should mention that distributed systems are much, much
better with experimental, throw-away branches because you don't have
to clutter up a central repository with everyone's experiments.

Cheers,
Walter Landry
wlandry_at_[hidden]

[1] http://superbeast.ucsd.edu/~landry/ArX/ArX-2.2.0/tools/arch-pqm/arch-pqm.html
[2] http://web.verbum.org/arch-pqm/
[3] http://blog.reverycodes.com/archives/000028.html
[4] http://subversion.kicks-ass.org/perfnew/
[5] http://www.contactor.se/~dast/svnusers/archive-2004-09/0682.shtml