how can I develop a pitfall-test and performance-test for merging files under different source control systems?

Question

Where I work, we've been using Subversion for years (apparently, I've not been here that long). There's some people here who'd prefer to use TFS, some who'd prefer to migrate to Mercurial and some who'd prefer to keep status quo. Other source controls (Git, others) won't fly because of poor Visual Studio integration.

The biggest issue/fear that a new source control would attenuate is fear of branching / merging.

I'd like to build a test that directly addresses which source control is better at merging two branches. Considering there probably isn't a "demo" version of TFS, it might be difficult. Still, it seems like an interesting problem.

To test this I'd need to know the following:

• What is a merge algorithm typically bad at?
• Can I find information on what merge algorithm a source control system uses (specifically TFS)?
• Can I come up with any advantages that one merge algo would have over another?
• What types of files do most VCS have trouble with?

More importantly, are any of you aware of someone who has already done this?

Answer 1

Regarding TFS, you have a small Branching and Merging Primer, which may not take into acount the fact that branches became first-class citizen with TFS2010.

You can see problematic merges in this Merging: hg/git vs. svn question (about Git initially, but can be generalized to other VCS): any kind of criss-cross merging is generally difficult to handle properly.

From there, you can also refer to:

• What makes some version control systems better at merging?
• Why is branching and merging easier in Mercurial than in Subversion?

Most VCS won't merge binary elements (except some like word documents).

Answer 2

I'm not sure you are going to find much use in a performance test for the different tools. All of the tools are fast with regards to resolvable merges. The problem and point of comparison is how often they result in conflicts. TFS 2008 and prior were terrible at resolving conflicts. 2010 is on par with any other system I've used, including Git. You may find ney-sayers there, but they are thinking of 2008 (admittedly very bad at resolving merges for you).

The key is to push or pull often. If you branch off, make sure you pull from the parent branch often. The longer you are away, the more chances for conflicts. This is especially true of generated files such as resx files and .xxproj files.