How to merge project files after a branch

[bushidocoder]

My company is looking to migrate to Vault from a collection of VSS and Subversion. So far, Vault seems to meet all of our expectations and then some.

I'm concerned by one thing however - our principal reason for upgrading is improved branching and merging. All of our project are organized as Visual Studio projects. When users add or remove files from a project (which happens quite a bit, particularly with database projects) in one branch, and we try to merge those changes back into another branch which has also had files added/removed from the baseline, can Vault merge the project files safely? I've seen references to being unable to have multiple checkouts of project files elsewhere in the forum, which implies to me that Vault can't merge the two - Unfortunately, given our current process, that's probably a deal breaker.

How do other teams manage this? Is this asking for too much?

-Steve

[dan]

The project file is text based, so Vault can theoretically handle it, like any merge tool would. The problem is that the project files are "machine generated" by Visual Studio, and sometimes a small change in the project can cause the file to be greatly different, and might cause the merge tool to report lots of conflicts (think of an XML file that is modified in one place, but the formatting of it changes on every line).

I think VS is getting better at only modifying the parts of the project file that actually change, so it should make merges more practical.

I guess the only other thing I would mention is that Vault's merging capability should be no different than any other tool you might use, like Araxis, etc. They all use text based merging, and I'm not aware of a special tool that specifically merges Visual Studio project files.

[bushidocoder]

As a matter of process, how do you deal with adding/removing files from Visual Studio projects (if relevant) and verifying the merge. In my tests with Vault, if I list .csproj and .sln files as unmergeable, I can't seem to bring up a visual diff of the two files to even merge them by hand.

Also, is it possible to add custom merge modules for certain MIME/file types. For our development with Subversion, we wrote a bit of custom code that would merge Visual Studio project files around XML nodes instead of individual lines to preserve the integrity of the data within.

[dan]

As a matter of process, how do you deal with adding/removing files from Visual Studio projects (if relevant) and verifying the merge. In my tests with Vault, if I list .csproj and .sln files as unmergeable, I can't seem to bring up a visual diff of the two files to even merge them by hand.

In the admin tool, you can specify .csproj and .sln as mergable files, which will allow you to see a visual merge. We don't enable these by default for the reasons cited above.

Also, is it possible to add custom merge modules for certain MIME/file types. For our development with Subversion, we wrote a bit of custom code that would merge Visual Studio project files around XML nodes instead of individual lines to preserve the integrity of the data within.

It is not yet possible to specify a merge tool for just a specific type of file. We'll add this as a feature request.

[irodriguez]

How did this work out for you? Run into any issues when merging the .csproj files? I would think that merging the .sln files may cause problems since adding a project would involve adding a folder to the repository first... or did Vault detect the new project and create the folder for you?

Thank you for any pointers!

[dan]

On an individual .sln file merge, Vault would not automatically create the project structure required - it just merges the contents of the file. However, if you used Merge Branches, it would detect new files in the one tree and add them in the other.

I am curious myself how well merging of .csproj and .sln files happens in practice. We don't do this here on real projects (it isn't part of our process), so our testing is done on test projects rather than real ones, which can reveal different issues.