Symptoms of a centralized VCS

Reading the TFS 2010 Branching Guide on CodePlex (no, I’m not a glutton for punishment, just want to know what else is going on in the world), I found an interesting note on scratch or temporary branches that pretty much sums up a lot of the drawbacks of centralized VCS like TFS and SVN (emphasis mine):

“Scratch” or temporary branches

Before creating a new branch for an individual to “play in”, prototype, or test changes in – it may be helpful to ask the following questions to see if there is a better alternative to creating a new branch. Using the options below may expose another area where the developer should be working, will prevent low quality, orphaned, or inappropriate code from getting into your source tree.

  1. Can you use a shelveset? Frequently developers just want a way to save or share changes. A shelveset accomplishes both of these tasks by saving the changes in the TFS database but not committing them to the branch.
  2. Is there another work item you should be working on? Sometimes other work is not visible to the individual engineer.
  3. Work in the “next version” branch mentioned above if the change is approved for next version release.
  4. If the work is truly not related to the project and for developer training use TFS 2010 “basic edition” to create a stand along TFS instance right on the developer desktop. This is completely separate from the production TFS that the team may be using. Consider using this for projects the developer would consider “throw away” (i.e. training) code.

The goal here is to keep the bar fairly high for creating a branch to keep the team focused on contributions that will help the current product ship or get an early start on the next version of the product. Every extraneous check in has an operational cost (i.e. storage, back up time, restore time, performance, etc.) so should be avoided.

Contrast this with Git:

git checkout -b TopicBranchName

Presto, a local branch that may or may not ever get back into mainline development. All of the alternative options listed are mainly focused on making sure that the centralized VCS repository stays “clean”. In a DVCS, I don’t run into that problem. I can create local clones, local branches, none of which never need to make it up to the server. All the operations are local, insanely fast, and don’t require an internet connection.

If I have to worry about the operational cost of commits (check ins), is that really a VCS tool I want to use? This isn’t really a TFS problem – SVN managed branches in a similar manner. It all comes back to the real disease – using a centralized VCS system.

About Jimmy Bogard

I'm a technical architect with Headspring in Austin, TX. I focus on DDD, distributed systems, and any other acronym-centric design/architecture/methodology. I created AutoMapper and am a co-author of the ASP.NET MVC in Action books.
This entry was posted in Tools. Bookmark the permalink. Follow any comments here with the RSS feed for this post.
  • I agree in principle with the reasoning behind this. Centralized stuff requires all kinds of work backing up and keeping things clean. However creating a local branch, while still maintaining the versioning control, means that you’re at risk of losing your work. What happens if your drive crashes or even you accidently delete your branch? While I don’t agree with TFS and it’s machevellian ways, infrastructure is good. Yes, I could have a backup for my local drive and if I’m an indepdent developer that’s what I do (I have dual backups at home to both my own NFS and the cloud) but for corporate developers this isn’t a reality. I think one of the key strengths with git is the offline and localization however with git power comes git responsibility so people have to know that if they’re not saving code to a managed system they need to manage it themselves. Not something everyone remembers to do.

    • I don’t know Bill, for something as expensive as TFS, you’d think that they wouldn’t be actively discouraging branching.

      Branching is an important part of proper development, and to tell you not to do it is kind of a joke.  It’s like buying an SUV then they tell you not to put it in 4 wheel drive.

      • TFS isn’t expensive anymore, although not free like other vcs.

        I’m actually more shocked that they discourage checking in than what they said about branching.  

        • You need to buy Visual Studio with a 1 year MSDN subscription to get TFS for “free”, of course if you want Ultimate, that’d run you just $11,800.

          Premium, which is the minimum that any developer should use is $5,500

          Yes, if you have some massive volume licenses, it goes down in price, but saying it’s not expensive anymore is just not accurate.

          Running a MS shop is ridiculously expensive, something most developers just don’t realize.

    • Ayende

      The way we usually do it, we have local branches + remote forks of the project.
      We usually share code via the forks, not directly pushing to central repository. That handles your “backup for local stuff” issue.

  • Chris Bristol

    We use TFS here at work and for the most part, it does a pretty good job of what we need it to do. It does at times get in the way, especially if it gets disconnected, and branching/merging as you mention. However, there are a few things it does well, like integrate with Visual Studio and MSBuild, and track renamed/moved/deleted files. I’m definitely not an expert on using DVCS, but from my limited knowledge, I seem to recall that using one didn’t handle those operations particularly well. It may very well be that issue has less to do with DVCS vs CVCS, and more to do with IDE integration though. How does GIT handle them?

    Also, I think you have a typo in this sentence: “I can create local clones, local branches, none of which never need to make it up to the server.”

    • Anonymous

      I turned off integration with the IDE, since I’m going completely from the command line. I haven’t really run into issues with renamed/moved/deleted files, but IIRC TFS handled these things explicitly.

      We use TeamCity, which integrates with pretty much any VCS under the sun. TFS does have a strong vertical integration story, but that’s also something we like to leave flexible on our side.

    • Scott MacLellan

      Actually Chris, renaming/moving/deleting are absolutely horrid in traditional centralized VCS like SVN whereas DVCS treat these as first class. In fact accepting patches, merging and basically any way you can exchange code is a first class citizen. It has been a while since I used TFS but if it does any better than SVN you are lucky.

      While these are normally okay in a standard branch the real test is how what happens when you perform these operations then preform a merge. In SVN this leads to tree conflicts ( whereas almost any DVCS will be able to perform the merge without any issues at all.

  • i’m in shock, having read that text. i can’t believe anyone would accept that as the way you’re supposed to work… utter disbelief at the incompetence of TFS in handling branches and (mis)guiding developers.

    yeah, svn has difficulty with branches compared to Hg or git… but i ran branch per feature and other branching strategies in svn for years, with no issues like they are referring to.

  • Actually, my favorite part of the text is:

    2) Is there another work item you should be working on? Sometimes other work is not visible to the individual engineer.

    Which is basically Microsoft saying:  ”Don’t you have anything better to do?”  Crazy.

  • I think TFS is more expensive compared to others.. IS it right?.. Those principles are very helpful to everyone.. Thanks a lot..

  • Javier Crespo

    Well, I guess that the question is still fair. Do you really need to branch in the first place? Different approaches are possible without breaking Continuous Integration.

    Not saying that branches are evil and sometimes they are the best choice (when you need to support past releases for example), but it’s clear that branches and CI don’t mix that well.

    • Anonymous

      Branches and CI mix perfectly well. We do CI-per-branch, no matter what our branching strategy, and it works just fine. You have to use a modern CI technology, though. It takes maybe 30 seconds to set up a new CI for a branch, with no builds contending with each other.

      When we used a sub-par CI server, sub-par build scripts and sub-par VCS approaches, then it didn’t work.

      • Javier Crespo

        You’re speaking about CI within the branch ( CI-per-branch). 
        What about continuous integration across branches? At some point your branches will be merged to the master and it will be at that moment the real integration will happen.  

        • Anonymous

          Not sure what’s different here? Master merges to branch, CI, then branch merged back to master. No matter what the semantic meaning of the branch is, the integration is the same.

          We might have additional gates on integration/dev/QA/production branches though.

          • Javier Crespo

            As long as you merge often to the master it’s ok as the real continuous integration happens in the master.  If you don’t merge often to the master,  even if you have a CI build your effective continuous integration will be broken as changes in the branch will take much longer to integrate…
            If your team has the discipline to avoid long-lived-never merged branches, then it’s ok IMHO. It takes discipline though…

          • Anonymous

            If we’re doing branch-per-feature, branches tend not to live long as we can keep features small (1-5 days)