#SUBVERSION CONFLICT RESOLUTION CODE#

My recommendation would however be to just remove it from your source control to begin with. It is also for this reason that you can resolve the conflict (if you want to) any way you see fit. It will only cause endless conflicts because no two users in a development team would have the same settings. suo file should not be stored in source control.

#SUBVERSION CONFLICT RESOLUTION CODE#

If however you feel that fixing the conflict is better, you can do it whichever way you like (‘Resolve using theirs’ or ‘Resolve using mine’). Obviously your personal settings in Visual Studio don’t make any difference to the actual code of your solution. It does not need to be in the code repository. suo file is actually really easy. You can just simply delete the conflicted suo file from Subversion. The solution user options file is used to store user preference settings, and is created automatically when Visual Studio saves a solution.” Fixing the Conflicted suo fileįixing your conflicted. You save user information into streams with the name of the stream being the key that will be used to identify the information in the. “The solution user options (.suo) file is a structured storage, or compound, file stored in a binary format. TortoiseSVN to do work and commit changes to the repository Deploying to the www/live/production server Recovering older versions, conflict resolution. suo extension stands for ‘ Soluton User Options’. It should come as no surprise then that the. Other settings also include your Visual Studio window layout (do you have Server Explorer window open. These settings are the locations of all your breakponts for example.

suo file is actually just the file that contains user-specific Visual Studio settings. suo file will tend to move into a conflicted state with everybody checking in their. suo file as well? Conflicted suo fileĪs soon as we start working in teams, the. We all know that we should ignore the bin and obj folders, but why is it that so many developers check in the. suo files in Visual Studio projects checked out of the SVN repository. I can actually see this tendency in the occurrence of conflicted. Somehow, I feel that we should learn more. Call it knowing just enough to be functional, call it lazy, call it what you want. Once we are comfortable with what we know and can work with, we somehow fail to learn more. The same can be said of what we know about the tools we use. Why re-do work if you can do it once and re-use. Unfortunately I know it as well as I need to, which is a totally different thing. I must admit that I probably don’t know it as well as I should. I have been using SVN as my code repository for years now. Conflicted suo files are the bane of every developer’s existence.

Subversion conflict resolution