views:

1353

answers:

3

Hi,

I have a VS 2008 project under TortoiseSVN source control. I am the only person using it at present.

I was trying to commit my latest changes when I received the message "File abc is out of date - please update". When I try to update the project, I get a whole set of file conflicts (binary and text). Since I am confident my working copy contains the correct version of the files, I try to resolve the conflicts by selecting "mine" as the correct version. I have also tried just marking each file conflict as resolved. I am then able to commit.

However, following this my VS 2008 project refuses to compile, and gives hundreds of errors (so many errors that VS 2008 reports that there are too many errors to show!). Something about TortoiseSVN's conflict resolution completely screws up the project, and it refuses to build.

Any way I can force TortoiseSVN to just save my working copy into the repository as the latest revision, without checking for conflicts?

A: 

Visual Studio and TortoiseSVN don't play nice together. One thing I've noticed is that you can't successfully version anything in a build directory, because VS thinks it "owns" the build directories, and is likely to delete your .svn folder (is this just for builds involving a clean?)

You might look at a Subversion client that integrates into Visual Studio. AnkhSVN springs to mind, but a good starting point to research this would be http://sharpsvn.open.collab.net/. Alternatively, you might consider using sharpsvn directly from a pre- or post- build task, or perhaps a macro in Visual Studio.

Dominic Cronin
I have been using TortoiseSVN and Visual Studio together for a good number of years and have never had a problem. The best practice for many reasons is to ignore the bin and obj folders and have a build server xcopy final build output to a specific folder to be checked in if necessary.
Chuck
It would be great to be able to work with SVN directly from VS. Am checking out Ankh now. Thanks!
Wild Thing
+1  A: 

I have found that Visual Studio project files are fairly prone to automated merging issues. The problem is that the format of the files is so repetitive, the merge utility has a very difficult time determining if a change is an addition or a modification. Also, some actions seem to cause Visual Studio to rearrange entires in the project file. Again, these changes are relatively difficult for the merge utility to handle correctly.

I rely on one of two options to fix this. First, you could open the project file in notepad and fix it by hand. They are not that complex and you can usually just follow the pattern and make sure nothing is out of place.

The second approach would be to revert the project file and then add and remove files and make other changes as needed in Visual Studio.

If commits are made early and often, neither of these tasks is too complex. If bombs are being dropped on the repository, well, this is one of the many reasons why committing early and often is a good idea. =)

Chuck
+3  A: 

I hope you've made a backup of your working copy before updating, because else it is most likely that the conflicts have led to a huge pile of >>>>>> theirs and <<<<<<< mine comments in your source files.

While I don't understand how the conflicts could happen in the first place (since you are the only one committing to the repository), there is a possible fix.

Move your current, "working" working copy to a safe location. Check out the project completely fresh. Copy your source files over the fresh working copy and then commit the resulting changes.

When your source tree consists of several directories, it might be tedious to copy every directory individually. To overcome this you can export your safe "working" working copy using TortoiseSVN -> Export All. This creates a directory without all .svn files and directories. You can then copy this exported directory over the fresh working copy.

Ole
I was trying to think how best to describe this solution, but you got it first.
Neil Barnwell
Brilliant! Thanks!
Wild Thing