On Thu, Mar 22, 2012 at 7:47 AM, Philippe Vaucher <philippe.vaucher@gmail.com> wrote:
Hello,
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 ( http://www.ericsink.com/vcbe/html/dvcs_advantages.html, http://www.ericsink.com/vcbe/html/dvcs_weaknesses.html):
Pro:
- 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.
Cons:
- 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 offline.
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. --Beman