DVCS, YAVCS or something more?

Curtis pointed me to this interesting article questioning the hype surrounding distributed version control systems (DVCS -- ya, I hadn't heard the acronym before either).

I generally agree with him, but some of the comments were especially illuminating.  In particular, I like the comment that it turns the relationship around: rather than a master "pushing" changes out to the masses, everybody has the option of "pulling" from whoever they like.  I can see how this is particularly valuable in an open source environment without strong leadership, though less so in a commercial environment or an open-source community with a strong "mainline" (eg, Firefox).

The only feature that jumps out to me is offline commit, merely because I spend a lot of time offline (or did, until I got a laptop with built-in Sprint wireless broadband -- kick ass!).  And the proposed "waypoint" addition to SVN would get me 80% there.  (The other 20% would be sharing waypoints with other users, but in my experience that's an incredibly rare operation.)

But regarding the claims that DVCS is somehow fundamentally easier to use or less prone to weird boundary conditions (eg, "Git rocks because I hate it when I delete a modified uncommitted file using the OS after renaming the parent directory a prime number of times in a row"), I'm skeptical.  Every VCS has dark corners where none dare tread.

Similarly, the claims "it's hard to set up a SVN repository" are pretty weak: cvsdudersync.net?  Or even SourceForge?  Likewise, setting up a local repository is kinda missing the point in a world of cloud computing: whether you like it or not, your laptop *will* break and your hard drive *will* fail.  Anything worth version controlling is worth backing up remotely, and SVN is as good a tool as any for that.

And finally, maybe I'm just really missing something, but I just don't get the value of extreme branch/merge.  I don't feel its complexity is what's preventing me from doing it -- I just never feel the need.  Indeed, it seems to go against the "continuous integration" ethos of agile development: I'd much rather have a bunch of somewhat-broken code prematurely integrated than somewhat-broken code integrated too late at the very end.

Granted this is probably due to my history of working with small teams on tight codebases (where everybody constantly affects everyone else): I can imagine how branching/merging becomes more valuable as team size and developer-decoupling increases.  And granted, I only very rarely submit or accept patches from contributors without direct commit access.

But all told, I agree with the B-List that the whole thing seems over-hyped.  It's a tool.  There are lots others.  Pick whichever one you like and get to work.

-david barrett

No comments:

- Jan 2014 (1) - Mar 2012 (1) - Nov 2011 (1) - Oct 2011 (1) - Apr 2011 (1) - Mar 2011 (3) - Feb 2011 (2) - Jan 2011 (9) - Nov 2010 (1) - May 2010 (1) - Mar 2010 (1) - Feb 2010 (1) - Jan 2010 (1) - Dec 2009 (1) - Nov 2009 (1) - Oct 2009 (1) - Sep 2009 (1) - Aug 2009 (2) - Jul 2009 (1) - Jun 2009 (4) - May 2009 (3) - Apr 2009 (3) - Mar 2009 (10) - Feb 2009 (5) - Jan 2009 (3) - Dec 2008 (5) - Nov 2008 (5) - Oct 2008 (5) - Sep 2008 (4) - Aug 2008 (5) - Jul 2008 (11) - Jun 2008 (8) - Feb 2008 (1) - Aug 2007 (1) -