Print

Windows & .NET Watch: Get onboard the DVCS train



Larry O'Brien
Email
December 15, 2010 —  (Page 1 of 3)
On the first project in which I used a Distributed Version Control System, I wondered what was such a big deal. Version Control is, it seems to me, one of the less interesting aspects of software development, an unfortunate artifact of the extraordinary plasticity of our work, shared source code, and the reality of dead ends and bugs. Now I’m fully converted. But I’m getting ahead of the story.

We used to say that using version control was one of the tell-tales between amateur and professional developers. In those days, version control used a “check-out, check-in” model. It was like a library: If you needed to touch a function, you made a request to the central repository. If no one else had checked out the file, you would be granted the global lock, which you’d retain until you checked the file back in.

It was undeniably intrusive, especially in the pre-object-orientation days when modules were generally structured in functional categories or abstraction levels. While a trivial programming task might only touch a file or two, harder tasks were generally spread broadly throughout the codebase, and it was common to be thwarted by the need to make a single-line correction in some large file that had been checked out for days by someone struggling with a function hundreds of lines away.

The advantage of the library model was that it forced a deliberate consideration of whether a change was appropriate or not. Additionally, it pressured you to make minimal change sets; the organizational pressure to hold a minimum number of check-out locks encouraged a quick, single-file check-in after the common situation of making a besides-the-point refactoring or small change.

I suppose it was in the late 1990s when the “lock-free” model of version control made rapid gains. This is the model that most of us use today: One is free to change any file in the project, and at check-in, one must reconcile situations where your changes conflict with changes introduced since you had begun work. This model is reliant on text-comparison algorithms that attempt to automatically merge files. These algorithms do tolerably well, although I’m sure we’d all be appalled if presented with the number of minutes we’ve accumulated manually fixing merges after our diff tools “got confused.”



Related Search Term(s): version control systems

Pages 1 2 3 


Share this link: http://sdt.bz/35085
 
Most Read Latest News Blog Resources


Comments


12/16/2010 06:20:39 PM EST

Good article. Your train metaphor & Vincent's branching model diagrams are helpful. The VCS history and perspective is entertaining and reminds me a bit of my (somewhat contrived) March post on this subject. Check it out (pun intended) at: http://derekwilliams.us/?p=1546.

United StatesDerek Williams


12/27/2010 09:18:50 PM EST

I don't understand what you are trying to say, DVCS or CVCS both encourage small change set, none promote long live branches. DVCS won't solve merge conflicts any better than any other merge tracking VCS and if you have your developers change the same lines in the same file or make logical conflicting changes (because they are not in each other's way that day) won't make you any more effective/productive. It might be hip, but CVCS have had branch and merge for ages and the same good practices still apply to DVCS:es. Branches were never about true parallell development (which is ineffective/unproductive), it is, as I see it, an anti pattern, because it means your code has a small (albeit hard to fix) where two disjoint functions requires changes in the same class. branches have always been about clean change sets (no matter if it is a feature branch, maintainance branch or development branch).

SwedenNiclas Lindgren


Add comment


Name*
Email*  
Country     


  • Comment
Loading




close
NEXT ARTICLE
News Briefs: August 1, 2008
Microsoft and ASG team up to create an API connecting their products, DevExpress has a beta of its AgDataGrid suite for Silverlight, and TotalView's source debugger has been updated to allow it to run on the Cell Broadband Engine architecture Read More...
 
 
 
 
News on Monday
more>>
SharePoint Tech Report
more>>


   

 
 

Download Current Issue
MAY 2012 PDF ISSUE

Need Back Issues?
DOWNLOAD HERE

Want to subscribe?


 
blogs tab
Creation
To write better software, cultivate your ability to be creative.
05/19/2012 07:40 PM EST

Slick...but who needs it?
compilr.com is a well-designed site and the folks behind it seem to have their heart in the right place. But...who needs it?
05/16/2012 12:45 PM EST

How to be a better software developer
Want to be a better developer? You won't get there by mastering an interesting language or learning a new set of APIs.
05/14/2012 12:18 PM EST

Wooing Galatea
Do yourself a favor and check out Galatea 2.2, a wonderful book by novelist Richard Powers.
05/12/2012 07:05 PM EST

The world as story
An artificial-intelligence system at Carnegie Mellon seeks to understand the world by making statements about it.
05/10/2012 06:39 AM EST

The Rise of the Brogrammer, or the Rise of the Sexist Programmer?
Women in Silicon Valley get vocal about sexist ads and campaigns that contribute to a tense work environment.
05/09/2012 03:14 PM EST

 

Events calendar tab
5/23/2012 to 5/24/2012
Chicago
IEG

6/3/2012 to 6/7/2012
Orlando
IBM Rational

6/10/2012 to 6/15/2012
Las Vegas
SQE

6/10/2012 to 6/15/2012
Las Vegas
SQE

6/11/2012 to 6/14/2012
Bellevue, Wash.
AMD