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 overrode 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's 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 early, 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.