David Abrahams <dave@boost-consulting.com> wrote:
Walter Landry <wlandry@ucsd.edu> 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. <snip>
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 control system. So it really sounds like you should see how well the new host works with CVS before committing to svn. Cheers, Walter Landry wlandry@ucsd.edu