Why shouldn’t we enjoy the benefits of distributed version control systems (DVCS) on Windows? I agree that we’ve made a start, now that, at last, we have a measure of integration into TFS and Visual Studio of Git, and with Atlassian porting SourceTree, their Mac client for Git and Mercurial, to Windows. This is fine as far as it goes, but neither of these products makes DVCS easy. I don’t just mean easy for developers but also for other roles that ought to be using it but mainly aren’t, such as DBAs and System Administrators. Before this happens, DVCS needs to be easy to pick up, and understand, without an expensive training requirement.

Even for the most experienced developers, version control, distributed or otherwise, can be a nagging source of annoyance, something that they are forced to think about, when they want to focus on writing code. When a simple fix to a website, as described in this issue’s Bureaucracy Free Development, requires branching, pulling, merging, it can become a drain on the spirit.

If even developers well drilled in the art of DVCS feel the weight of its anchor, I fear for the morale of those making the crossover from VSS. Though VSS wasn’t much good at version control, its pessimistic check-in/edit/check-out locking model was at least easy to comprehend and control. The world of DVCS is a wild, rich jungle by comparison, with developers constantly pulling, branching and merging the latest changes. It’s very easy to take a wrong turn and force a change on the ‘remote master’ that disrupts or overwrites the work of all other developers in the team, or to perform a complex merge when a “rebase”, whatever that is, would have been a better choice.

Developers moving to a DVCS from a centralized VCS such as Subversion are not immune from grief either. The switch from TortoiseSVN to TortoiseGit is relatively simple but a failure to appreciate the expected changes in workflow can cause the same problem, as described graphically in articles such as Avoiding Git Disasters: A Gory Story.

Ultimately, the current “front end” tools are too close to the underlying commands in workflow. In other words, these tools are for people who already understand Git and understand the correct workflows through the various pull/merge/ push/rebase scenarios. Everyone else faces a hard time to learn what the tool does and what the workflow is supposed to be before even starting to use it. Some other tools, by contrast, are too generic to be able to exploit the advantages of a distributed system. They make an effort to abstract parts of the workflow, but when a conflict occurs, they often end up leaving the developer stranded with a number of arcane command-line actions to perform outside of the tool.

Why is the management of the DVCS process so hard for mere mortals? Programmers seem to be at that the same point now that accountants used to be before the development of the Spreadsheet. Before Dan Brinklin had a moment of inspiration in 1979, whilst doing a course in bookkeeping at Harvard, computers had no universal analogy, or representation for this sort of task. With version control, we have the mechanism now, but no easily understandable representation of it. As soon as someone thinks of it, we’ll all be using it.

Cheers,

Tony.