Click here to monitor SSC

Tony Davis is an Editor with Red Gate Software, based in Cambridge (UK), specializing in databases, and especially SQL Server. He edits articles and writes editorials for both the and websites and newsletters, with a combined audience of over 1.5 million subscribers. You can sample his short-form writing at either his blog or his author page. As the editor behind most of the SQL Server books published by Red Gate, he spends much of his time helping others express what they know about SQL Server. He is also the lead author of the book, SQL Server Transaction Log Management. In his spare time, he enjoys running, football, contemporary fiction and real ale.

Aversion to Version Control

Published 28 February 2013 2:51 pm

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.



6 Responses to “Aversion to Version Control”

  1. Sergio E. says:

    I think that one of the problems with the dcvs like git is the chaos that can be easily generated and introduced into the source control repository.

    I have beginning in the git world with a very small project with 2 more people, and today, make consistent all the code between branches it begining to consume more time than the programming time.

    And this is due the lack of the lock control over the files that other sistems has, for example sourcesafe, wich let you get all the code but only the checked out to edit can be pushed to the repository by the last writer and all other programmers can only read it but not modify.

    So, having experiences like that make me (as programmer) to think even more about going back to a non distributed source code versioning system.

  2. philp625 says:

    Great job summing up my problems with today’s source control solutions! I suspect many other shops would agree with you.

    I have spent the last two years trying to decide what to migrate my team to when we finally ditch VSS. None of the current tools meet my needs without making my head spin. Very frustrating, and because of it, my search continues.

  3. Keith Rowley says:

    You hit the nail on the head with this one. Distributed Version Control Systems are still too hard to use and thus can be a drag on productivity. Yes they offer great opportunities and possibilities, but the practical realities make them overly hard to use for normal developers. (And most developers are basically smart cookies with good computer and problem solving skills, so this is saying something.)

  4. Timothy A Wiseman says:

    Unfortunately, DVCS are inherently complex. They give you many options and a wide array of handling the challenges that arise, but that same breadth of options gives rise to a steep learning curve. This is something that I am continuing to face personally as I use Mercurial in my personal projects, though I use VSS at work which is much easier to understand but has fewer options.

    Eventually, I am certain that someone will be able to cover over most of the complexities and let the average user make use of their routine features simply. I suspect much of the complexity, and perhaps even more, will remain under the surface for more advanced users of DVCS to access and use when necessary. But I do not expect this to come imminently and am continuing to ascend that steep learning curve in the meantime.

  5. paschott says:

    We switched over to Git from TFS a couple of years ago and haven’t had any major problems after the first month or so of learning pains. We’re careful to separate out functionality into different feature or story branches, work in those, merge regularly from master/mainline into those branches to avoid pain later on when merging work, and commit as needed. The advantage of working offline and disconnected has helped us more than hurt.

    One thing we found that didn’t work was the lack of checking out files/folders when working with our help system. People were constantly running into issues as someone re-orged the file/folder structure and everyone lost their changes or wrote conflicting files. They switched over to SVN or something else that would allow that functionality. For our developers, we have a pretty consistent file/folder structure and rarely do a “move” of files so it works pretty well.

    Even for our SQL Projects, the DVCS system has worked well. The worst I had was a timeout in fetching files from one of our servers, but that was worked around by seeding my folder with a starting set of files.

  6. Greg Gaughan says:

    I’ve tried to use git instead of subversion off and on for a couple of years, and have come to the conclusion that it’s just not fit for standard projects. The command syntax seems deliberately obscure and gets in the way of coding.

    The ideas behind it however are useful, and a DVCS called ‘fossil’ does seem to go a long way towards making those ideas straightforward to use without getting in your way.

    Here are some quotes comparing fossil with others: Fossil quotes. I think it’s worth consideration.

Leave a Reply