We are using SVN externs to selectively pull in revisions from a “Framework” Project which functions as a code library for our app. Our SVN process is to create a Working Copy from a DEV folder in the repository, commit to DEV, and then subsequently svnmerge (via a script) from DEV to a TRUNK folder which forms the basis for our deployments.
I put some code into the Framework library and therefore updated the svn externs for the Framework folder in our app. I then did a SVN Commit to DEV and was subsequently ambushed by a SVN Conflict on the Framework folder when executing our merge-from-dev script when preparing TRUNK for a deployment.
SVN Goes Stalinist
In order to view the conflict in Tortoise SVN, I created a SVN branch from TRUNK itself, but Tortoise SVN did not have any option for “Edit Conflicts”, “Resolve using mine” or “Resolve using theirs” under the “Check For Modifications” Context menu or anywhere else. In a cruel parody of Stalinist democracy, all it had was the “Resolved” option. There were no .mine or .rnnn files for the folder. In addition, the Folder still had the old externs in place in its SVN Properties. How to resolve the conflict AND get the CORRECT svn extern settings into the Folder properties ?
Solidarity in the Dialectical Struggle
Our site SVN expert showed me the ACTUAL file which was in conflict which was the read-only hidden _svn folder which belonged to the Framework directory. He did this by simply enabling Hidden Files in the Folder View options. That revealed this sucker:
But even THIS file does not have .mine and .rnnn files generated for it; you still can’t do an “Edit Conflicts” on it because it’s read-only. So now we could see what was in conflict but couldn’t do any edits on the Conflicts.
What you CAN do, however, is a “Compare to Base”. This allows you to see what text in the svn Properties file has caused the conflict, which of course was our updated externs.
Using the principles of Russian Roulette-Driven Development I suggested we update the externs to the correct values in the TRUNK working copy then accept the only option Tortoise cared to present to us – namely “Resolved” – then blast away with a Commit to TRUNK…and it worked…
(but we did check the extern properties after clicking “Resolved” and before hitting “SVN Commit” – there are limits even to Russian Roulette).
Addendum 16-Apr-2009 : .suo File Conflicted
I noticed a few people accessing this post using the Google search terms ‘svn .suo file conflicted’. Fixing this one is easy – delete the .suo file from Subversion. If you really need to fix the conflict, do it any way you can ‘Resolve using theirs’ or ‘Resolve using mine’ are equally acceptable.
The .suo file should not be added to source control because it contains user-specific Visual Studio settings such as locations of your breakponts, the user’s VS window layout (e.g. do they have ‘Server Explorer’ window open and if so where do they want it located on the screen) etc. SUO stands for ‘Soluton User Options’.
Liberation From Wage Slavery
Personal settings in the VS IDE are irrelevant to the actual code in the solution and hence should not be stored in source control. All you will achieve is a meaningless SVN conflict because User TREV likes Server Explorer open in Visual Studio whereas user BRIAN does not. That’s why the conflict can be resolved in any way you like.
Be free, comrade! Kill from SVN disgusting suo file!
Here’s the MSDN spiel on what the .suo contains.