Subject: Re: [boost] DCVS vs CVS: call for constructivism
From: Beman Dawes (bdawes_at_[hidden])
Date: 2012-03-23 06:35:03
On Thu, Mar 22, 2012 at 7:47 AM, Philippe Vaucher
> I think we all know understood that there are people from both camps, some
> with emotional arguments, some with constructive arguments, but it's not
> really moving anywhere. We need to start listing what would have to be done
> and once we have such a map see if it's worth it before discussing
> pointless things.
> Just so we can redirect people saying things like "Nobody told me a real
> advantage yet" to this post, here's a recapitulation of what I think the
> advantages/disadvantages of a DCVS is (
> - Offline work (you can use diffs, you can commit)
That's just one example of more general advantage: distributed version
control systems support many workflows that range from messy to
difficult to downright impossible with non-distributed VCS systems,
and make it easier for different Boost developers to use a workflow
that suits their particular needs.
> - Speed of operations compared to svn
> - No need to setup a server to work locally (encourages participation
> (focus on working first, then sharing later))
What about ease of modularization and breadth of community support?
What about developer preference? My impression is that a sizable
majority of developers who have used both distributed and
non-distributed VCS come to prefer distributed.
> - Cannot check out subpaths
> - Cannot lock files
> - Would require people to change their habits and learn new tools
> I think most people in the svn-camp will tell that with the 1.8 checkpoints
> feature you can now also commit while offline and thus the only advantages
> for DCVS seems to be speed and the ability to check all the data while
Focusing on checkpoints trivializes the advantages of distributed VCS, IMO.
> I think the people that are opposed to the change unfortunately
> won't be convinced by those arguments, even tho pretty much every who
> switched to DCVS will tell you that the advantages are worth it and it's
> more than simply speed or freedom, it's a philosophy etc.
> So I think the best thing to do now is first to make a map of what would
> have to be done if we decided to switch, to see if it's an option at all.
> Here's a simple draft, please participate into making it better:
> - Import current history
> - Migrate the existing hooks
> - Migrate the existing scripts around.
> - Migrate the test runners
> - Trac / Website integration (redmine with git extensions?)
> - Rights management (gitolite?)
> - Update release procedures
> Maybe we'd start a page on the wiki, but the idea is to find out if there
> are more steps to be done and if there's any showstopper in those steps.
What you are suggesting seems to be what the Ryppl folks been working
on for several years now.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk