Two Sides of the Same Coin

Q: Earlier this year, you wrote the article "Source Control Basics: Shelving, Branching, and Merging" in which you made it clear that you weren't a fan of merging changes in source control. I agree. I recently installed Team Foundation Server (TFS) and set it up to be our corporate source-control library. Soon thereafter we found that multiple developers could, by default, access the same source file at the same time. Then at check-in, they were suddenly presented with a requirement to merge these changes. In some cases, the merge was relatively painless. In other cases, the merge was painful and has introduced errors. How do we disable this default?

A: I received several email messages about the "Source Control Basics: Shelving, Branching, and Merging" article. Another reader had wrote and said, "In your article 'Source Control Basics: Shelving, Branching, and Merging,' you claim that merging is bad. I completely disagree. My organization couldn't function effectively if multiple people weren't working on the same source files."

As you can tell, these two readers' merging experiences and opinions are diametrically opposed. The good news for the first reader is that you can avoid the situation entirely.

When you install TFS, the default is to allow for shared check-out of code files. This means that if developer Andrew has started editing a file on his local machine, then developer Betty also starts independently editing the same file on her machine, TFS, by default, lets them. Andrew and Betty might be completely unaware that someone else is editing the file because TFS doesn't tell them when a file is already checked out.

However, one of the developers will become aware of the situation during check-in. Suppose that Betty finishes editing the file first. She checks in her code with no problem. But when Andrew goes to check in his code, TFS will stop the check-in process and ask him to merge the changes. At this point, he'll generally have a couple options related to merging.

The first option is to allow TFS to automatically merge the changes. When this option appears, it means that the developers who had simultaneously checked out the source file had changed different lines of code. From TFS's standpoint, this type of merging is easy, but selecting this option isn't risk free. For example, Andrew and Betty might have both added the same line of code, but Andrew put his line of code at the top of a function whereas Betty put her line of code at the bottom of the function. Because they put the same line of code at different locations, TFS will include two copies of that line of code, which is an error waiting to happen.

The second option is to use the Merge Tool to manually merge changes. The bad news is that one developer (Andrew in this case) gets stuck with extra work. The good news is that the Merge Tool is fairly powerful. The tool highlights those changes it feels incapable of merging so that the person merging the code can select the change he or she wants to apply. That person can actually edit the resulting choice.

In theory, being able to manually merge changes sounds great. In the real world, however, I've found that manually merging changes can result in new errors and lost changes. In one instance, a client started experiencing problems after a mere 40 hours of development time. The problems started within the first day or two, but reached a head on the day of software cutoff. We had to spend so much time merging one developer's changes that the cost of making those changes to the application doubled. Some developers also claimed their changes were lost because of merging. The net result was chaos at a time when we were trying to manage what should have been a simple software cutoff scenario. Because of this experience and similar experiences with other clients, our policy as of last week is to always turn off shared check-out.

Here's how to disable shared check-out: Within Team Explorer (aka Visual Studio 2005) go to the Team menu. (You'll have this menu only if you've installed Team Explorer and are connected to a TFS server.) Select Team Foundation Server Settings, then the Source Control File Types option. A dialog box listing a variety of file types will appear. This dialog box has three columns, the first two of which contain the name of the file type (e.g., VB Files) and file extensions associated with that type of file (e.g., .vb). In the third column, which is labeled File Merging, you can specify whether you want to allow shared check-outs for that file type. To change the value in this column, click the Edit button. In the dialog box that appears, clear the "Enable file merging and multiple check out" check box.

That's it. You've now prevented multiple check-outs for files of that type. Even if a developer specifically requests a shared check-out, TFS won't let it happen.

Hide comments


  • Allowed HTML tags: <em> <strong> <blockquote> <br> <p>

Plain text

  • No HTML tags allowed.
  • Web page addresses and e-mail addresses turn into links automatically.
  • Lines and paragraphs break automatically.