From: Walter Landry (wlandry_at_[hidden])
Date: 2005-02-04 00:10:23
David Abrahams <dave_at_[hidden]> wrote:
> Walter Landry <wlandry_at_[hidden]> writes:
> > However, I am not a big fan of centralized version control, and
> > vastly prefer a distributed approach. Distributed systems let
> > people use version control when they are not connected to a central
> > server, so when the server goes down you can still get work down.
> ?? I get work done when disconnected from CVS.
You can't commit. So you can't try some designs, settle on one, then
realize a different design worked better and resurrect it. Basically,
you lose many of the benefits of using version control.
> > There are other differences, but I will spare you the details.
> > Realistically, no change will work unless a major contributor to Boost
> > gets religion and invests some time in learning one of them. All of
> > these systems, including Subversion, have their annoying differences
> > from CVS. It sounds like Subversion has such a convert with David
> > Abrahams.
> I'm not a "convert," and my experience with svn is limited. I'm still
> in the early phases of experience with it. SVN seems like the logical
> choice to me, but I'm open to considering others.
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. 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? 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. In any case, getting a new host (OSL) may
solve some of this.
there are constant stale locks,
This problem mostly goes away with distributed systems.
our occasional file moves are painful,
This goes away with any modern version control system.
and the anonymous pserver image lags the real one by an hour or
more. Oh, and SF's connection for getting the CVS tarball keeps
dropping, so it's hard for anyone to do automated backups.
These sound more like problems with sourceforge, not the version
So it really sounds like you should see how well the new host works
with CVS before committing to svn.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk