Re: [boost] DCVS vs CVS: call for constructivism

Subject: Re: [boost] DCVS vs CVS: call for constructivism
From: David Bergman (David.Bergman_at_[hidden])
Date: 2012-03-22 15:28:28

Constructive while insightful would be great, i.e., to hear from people have extensive experience with BOTH (kinds of) systems, rather than people being used to X and having heard (good and bad rumors) about Y.

I happen to be one; and for me, it is a no-brainer. That is not to say that I did not use my brain to some extent while concluding, constructively ;-), that Git is far superior to SVN.

Regarding learning curve: yes, the learning curve for Git is steep; it might necessitate one full day (...) of focused training to get the concepts and file system (abstraction and concretely) pieces. In my extremely humble opinion, it is well worth to allocate 10 solid hours into something one uses daily for at least seven years; especially for a tool like Git that actually does affect the way one approaches development processes a bit, and in my still humble opinion, does so in a positive way.

Come on guys, I promise that it is worth one full day to get into Git; if nothing else, it might invoke some (branching) thought patterns that could be useful for your SVN (or CVS...) efforts :-) Once, everybody involved in this discussion have indeed used both systems, we can have a truly constructive dialog.

Regarding not being able to check out sub paths and deal with them , that is not entirely true, as Git, at least, enables one to dissect a file tree, with commands like "git read-tree", "git write-tree" and "git merge -s subtree". Simple? Nope, but powerful.

That is actually a theme of Git: few and simple (graph-theoretical) concepts and quite hairy commands to get to them, with seemingly arbitrary names, hiding the simplistic beauty behind the scenes.

A huge PRO for Git is the simple command

        git stash

which hides away all the current local changes (and state) into a temporary stack, so you can resolve underlying/other issues and then get back to where you were via

        git stash apply

Very handy, and very frustrating not to have that in SVN.

/David

On Mar 22, 2012, at 4:47 AM, Philippe Vaucher 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)
> - Speed of operations compared to svn
> - No need to setup a server to work locally (encourages participation
> (focus on working first, then sharing later))
> 
> 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. 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.
> 
> I think the best solution would be to offer the repository with several
> protocols, namely git/hg/svn so everyone could use the tool they want (e.g
> github offers svn/git, I know other hosts do it too).
> 
> Philippe
> 
> _______________________________________________
> Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost