views:

868

answers:

7

We just switched from TFS to SVN, and so far we're loving it.

However, it did introduce a few new issues.

One is the way project files (.vbproj specifically) are handled. The .vbproj file is of course always changing as files and references are changed, and if a few people are collaberating there will be conflicts.

Oddly, in TFS we never had to deal with managing those conflicts, that particular piece was automagically handled. Now in SVN, we're mucking through XML in the merge tool and there have already been some mistakes.

How do you handle this? Any tips?

EDIT: by the way, we're using VisualSVN.

+1  A: 

This particular issue occurs if multiple developers add files to the same project.

To resolve a conflict when multiple developers have added files to the same project, you can usually make it work by resolving using "mine before theirs" option. It'll add both your changes together.

This issue and other merge issues are alleviated by committing and updating often. Commit once a day or more if possible. The longer you go without updating and committing, the more pain you and your team will feel.

Judah Himango
A: 

You need a decent client like Toroise. You do occasionally get conflicts in the auto merge, but ive never had one with the .vbproj and they are very easilly rectified with the diff program.

id use _svn instead of .svn, for several reasons, i can't remember why now off the top of my head but the "." did cause me grief.

make sure you dont commit .user and .suo files, otherwise you will keep getting each other VS settings for the project, annoying!

You can also get client add ins for VS like ankh and visual svn, ive only used ankh for a bit but it was a bit slow, but that was probably my PCs fault.

Andrew Bullock
_svn vs .svn was ASP.NET compatibility thing.
To be more exact, _svn is only needed when using Visual Studio .NET or Visual Studio .NET 2003, 2005 and higher don't have the bug
Sander Rijken
+5  A: 

In SVN the main problems with *proj files is when people move files around to different folders, and/or when they add and remove similarly named files simultaneously, usually at the start of the project.

Once filenames and project structure become more stable this won't happen as much anymore.

Also, only include the .sln and .vbproj files, don't include the ever-changing .suo files, to reduce headaches.

Jon Limjap
+1  A: 

What we generally do is update *proj file + add or move file stub + commit all at once. Make the operation as atomic and keep the duration as short as possible.

Joel Coehoorn
A: 

Are you sure your project file is not marked as binary? If your .vbproj file has a svn:mime-type property with a value that doesn't start with 'text/' Subversions automatic merging will be disabled.

When we converted from VSS a couple of years ago most project files were marked as binary. Removing the mime-type properties removed most conflict cases.

Bert Huijben
A: 

Try VisualSVN. It works in conjunction with TortoiseSVN to manage everything for you, and integrate Subversion functionality with Visual Studio. It also sets up svn:ignore for user-specific project files and binaries to save them being committed to the repository. Well worth the effort.

X-Cubed
+1  A: 

Try AnkhSVN. Very happy with Version 2. Out of the box it ignores .suo files, etc, works flawlessly with VS 2008, and it's free!!

David Cuccia