Visual Studio, svn and merging .csproj and .sln files

Question

Anyone had any success getting SVN to merge Visual Studio project (.csproj) or solution (.sln) files that have been edited by two users? Example

1. User A checks out project
2. User B checks out same project
3. User A adds a file
4. User A commits changes
5. User B adds a file
6. User B commits changes

Seems to me that at step (6), svn, Tortoise, Ankh or whatever should detect a conflict and either merge the two project files automatically or, more likely, prompt User B to resolve the conflict. Currently, we're seeing changes made by User A obliterated when User B checks in, resulting in bad builds, deploys, etc missing features that had been added before the last checkin.

Since the project files are XML, why is this an issue? Am I missing something here? I've searched the archives here and googled to I can't google no more, but haven't come up with a good solution.

Answer 1

How do you think you trick SVN into performing step #6? It seems you misunderstood what goes wrong. SVN will never ever commit from a working copy that's not up to date, so step #6 won't work without user B previously updating and merging user A's changes. Honestly. Try it.

I guess what happens instead is this:

1. A checks out project.
2. B checks out same project.
3. A adds a file.
4. A commits changes.
5. B adds a file, but forgets to save the project/solution.
6. B tries to commit changes and gets a message he should update first.
7. B updates.
8. B switches back to VS. VS tells him the project/solution changed on disk and asks whether he wants to a) reload from disk and lose his changes b) override the version on disk.
9. B doesn't understand, doesn't try to understand, considers his changes valuable, and picks b), overriding the changes on disk.
10. B still doesn't try to understand and thus does not diff the version he has on disk with the last committed one and thus misses that he deleted A's changes.
11. B Checks in, overriding A's changes.

I've seen this happening once in a while, usually with a user B who does not really understand SVN's (or CVS', FTM) workflow.

So here's a few hints:

Don't update unless you have saved everything ("File"->"Save All", for me, that Ctrl+Shift+S). In case you have made that mistake and you're stuck, do override the changes on disk and then merge the lost changes manually. (It might also work to update the project/solution file back to version N-1, and then to HEAD again, in order to have SVN perform the merge.)

Don't commit without checking which files you changed and having a quick look at the diffs to see whether the changes are what you expect.

Commit often. The more developers work on the same code base, the more likely you get conflicts. The longer you change your working copy without updating, the more likely you get conflicts. Since the number of developers usually is out of your hands, the update frequency is the one thing you can use to reduce the probability of conflicts.

Answer 2

A rather radical but efficient solution is to use a tool to generate those solution files from a meta-definition and then putting only the meta-definition under source control, not Visual Studio project files (which are a nightmare to merge).

In my team we use MPC to do this. We have:

• a bunch of .mpc files for project descriptions,
• a .mwc file for workspace / solution description,
• a small .cmd to generate Visual Studio files.

Since they are all hand-edited text files, we no longer have problems with Visual Studio mixing up everything.

The drawbacks are an extra-tool and the need to regenerate the solution files when files are added or removed but there are some additional benefits too:

• project configurations are centralized: for instance, changing a compilation flag is done in a single place instead of on a per-project basis,
• this can accomodate multiple build systems (we currently use Visual 2003 and 2005 but this also works with gcc and others).

From my experience, althgough setting up the tool can be a bit painful (but it all depends on the size and complexity of your project), this is clearly worth it.

Note that MPC isn't the only tool for this purpose. Others exist, such as CMake.

Answer 3

I second sbi's answer. One possible solution is to always update from within Visual Studio, at least if you use VisualSVN (I'm not sure how AnkhSVN copes with this situation).

VisualSVN will block visual studio during the update operation, and make sure any changed projects are automatically reloaded, so users can not ignore the external changes.