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

Question

Has anyone managed to get SVN for combining Visual Studio project files (.csproj) or solutions (.sln) that were edited by two users? Example

• User A checks the project.
• User B checks the same project.
• User A Adds File
• User A makes changes
• User B Adds File
• User B makes changes

It seems to me that in step (6), svn, Tortoise, Ankh or something else should detect a conflict and either merge the two project files automatically, or rather, ask user B to resolve the conflict. Currently, we see the changes made by user A that were destroyed during the check by user B, resulting in poor builds, deployments, etc., which were added before the last check.

Since project files are XML, why is this a problem? Am I missing something? I searched the archives here and searched Google, I can no longer google, but did not find a good solution.

Answer 1

Do you think you are fooling SVN to complete step # 6? It seems you misunderstood what went wrong. SVN will never commit from a working copy that is not being updated , so step 6 will not work without first updating user B and merging the changes of user A. Honestly. Give it a try.

I guess what happens instead:

• Verification of the project.
• B checks the same project.
• A adds the file.
• A makes a change.
• B adds the file, but forgets to save the project / solution.
• B tries to commit the changes and receives a message that he should update first.
• B.
• B switches back to VS. VS tells him that the project / solution has been changed on the disk and asks if he wants to: a) reboot from the disk and lose its changes; b) override the version on disk.
• B does not understand, does not try to understand, considers his changes valuable and chooses b), redefining the changes on the disk.
• B still does not try to understand and, therefore, does not differ in the version that he has on the disk, with the last fixed, and thus skips the fact that he turned over the changes of A.
• B Checks, discards the changes.

I saw this from time to time, usually with user B, who really does not understand the SVN workflow (or CVS, FTM).

So here are some tips:

Do not update if you have not saved everything ("File" → "Save All", for me it is Ctrl + Shift + S). If you make this mistake and get stuck, override the changes on the disk, and then manually merge the lost changes. (Perhaps this will also help update the project / solution file to version N-1, and then press HEAD again so that SVN performs the merge.)

Don't commit without checking which files you changed , and quickly look through diffs to see if the changes are what you expect.

Commit in advance, often complete . The more developers work on the same code base, the greater the likelihood of conflicts. The longer you change your working copy without updating, the greater the likelihood of conflicts. Since the number of developers is usually not in your hands, the refresh rate is one thing you can use to reduce the likelihood of conflicts.

Answer 2

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

VisualSVN blocks the visual studio during the update operation and ensures that any modified projects are automatically reloaded, so users cannot ignore external changes.

Answer 3

A fairly radical, but effective solution is to use the tool to create these decision files from the meta definition, and then put only the meta definition in the source control, not the Visual Studio project files (which are a nightmare for merging).

On my team, we use MPC for this. We have:

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

Since all these are manually edited text files, we no longer have problems with Visual Studio mixing everything.

Disadvantages are an additional tool and the need to regenerate decision files when adding or removing files, but there are additional advantages:

• Project Configurations
• centralized: for example, changing the compilation flag is done in one place, and not on the basis of each project,
• this may contain several build systems (we are currently using Visual 2003 and 2005, but this also works with gcc and others). A.

In my experience, creating a tool can be a little painful (but it all depends on the size and complexity of your project), it is definitely worth it.

Please note that MPC is not the only tool for this purpose. Others exist, for example CMake .

Answer 4

You can also try to reduce conflicts by ensuring that your project files do not list every single file within the project. This will avoid changing the project file in the first place when the user adds the file.

You can use wildcards inside the project file: see MSDN

Example:

<ItemGroup> <Compile Include="Src\**\*.cs" /> [...] </ItemGroup> 

Sadly, Visual Studio does not encourage such project customization and instead prefers to list individual files.

Answer 5

It is very tiring and tiring, so you just need to plow it. Sometimes you will keep a local working copy, as it adds all your user projects. However, in other cases, you will want to combine all the new elements from the base solution so that you get everything that was from both solution files. For ease of reading, it is best to add all the add-ons to the base product before adding settings.

Do not worry that the first part of the GUID is identical for projects, but the last part will be unique.

Fissh