Using SVN with Visual Studo C# Express

You can commit solution files, just make sure to ignore the *.suo files. You also should make sure to ignore the bin and obj folders as those are just created during build time anyway.

I personally use SVN for all my projects, no matter if they are in Visual Studio (most are), ruby, linux, whatever. I don't use the SVN source control plugin for Visual Studio however, because so many of your files are not usually in your solution (make files, art resources, documenation, etc) that it just doesn't make since to me to use checkin/checkout from VS half the time, and the command line or tortoise half the time.

You do commit *.sln and various proj files.

My svn ignores list for my Windows Development machines is:

global-ignores = *.suo *.user *.ncb *.aps bin obj Debug Release temp debug release

I don't remember what the *.aps is for (it isn't normally need it so you can leave it off).

You asolutely MUST not commit the *.suo and *.user files or you are going to mess up opening the files on different computers. The *.ncb file has varied a little over the course of visual studio, with VC6 they acidentally had some things you do want to commit in it, while having mostly things you shouldn't, so it was a pain. Now they cleaned it up (it seems to me) and I have never needed to commit them.

The rest of the list is just intermediate and output files from various versions of the tools (C# and C++ differ in convention).

Note - the SVN ignore list IS case sensitive, so you do need both cases of Debug and Release to cover all the different version of all the tools.

Also, if you only use one tool (say C# express, or C++ Express) you would have a much shorter ignore list.

Good luck.

Hi,

Thanks Xai and Rob!

Just a couple of clarifications needed.

Let say we have two users, A and B. A created a new folder name "test" while B deleted a file. If A commits, then B tries to, were there be a conflict between their .sln and project files?

Or if two users each add a new file to the project, will there be a conflict too?

Is it possible to resolve .sln and project files conflict by hand?

Thanks in advance!

Quote:

Original post by ExtrakunIf A commits, then B tries to, were there be a conflict between their .sln and project files? Or if two users each add a new file to the project, will there be a conflict too?

In most cases like this (also applies to two users editing one .cpp file) SVN will merge sources together. You must not worry about that. But if SVN will not be able to merge them, then it will display conflict and let your resolve it by hand.

Quote:

Is it possible to resolve .sln and project files conflict by hand?

Every conflist that happens with text files can be resolved by hand. So yes - .sln and .vcproj conflicts can be resolved by hand.

Certain types of edits cause a "merge conflict" - and two difference people adding doing 2 different file changes to the same project file is a situation that can cause that (but doesn't always).

However understand that this is true of all files, source code included, and the method of dealing with it is rather straitforward, and it does not happen invisibly, the tool will tell you there is a conflict AND give you all the information you need to deal with it. It simply requires a few manual steps.

First, I'm going to restate the assumption of non-locking source control systems. It is the duty of EACH person doing a commit to ensure that their changes work with the latest code. Which basically just means that they have to move up to the latest version that is commited, prior to commiting their changes. The svn source control system enforces this rule (unless you explicitly override it with command line switchs). What it does is check to see if any of the files you are commiting have changed in the repository since you checked them out. If so, it rejects your commit, and tells you why (not up to date). You then perform an update - which if all is well will simply merge the latest changes from HEAD in with your local changes, giving you a file that has both changes. Having been told there was an "out of date" error, generally you should restest your changes before you commit - or simply glance at the diffs from those updates, so you can reasonably assume they won't break your change. Once satisfied, you commit your changes.

However, if all is not well, there will be a merge conflict when you perform the update step. All this means is that the merging tool is not smart enough to eb sure how to properly merge two change together (which happens for instance when one person changes something, and another person moves it). In this case the tool spits out at least THREE versions, as seperate files. It gives you the version you had orignally checked out (for instance .63), the version that is newest in the repository (for instance .65 if 2 changes to the repository had happened since you last updated), and the version you had on your disk before you ran the update that couldn't complete (.mine) ... you can now see a diff showing the changes THEY made (diff .63 and .65) and you can see a diff showing the changes you made (diff .63 and .mine) ... or use a 3 way diff tool. Then you simply make a file that you feel is correct with both sets of changes (or whatever "right" would be). Usually what I do is copy the HEAD file (.65 in this case) and then repaste / make my changes into it. That way I know I started from their "working" code and performed the changes I felt I understood ... and am very likely to notice if they are likely to be incompatible.

Then you test and check in the merged version. To do this you have to first use the "svn resolved" command to tell subversion that you have manually resolved the conflict (it will trust you, since it isn't smart enough to know either way). Then run commit as normal.

Sounds like a lot of work and trouble ... and it would be if it happened regularly. But in my most recent experience on a 3 man side project working on a professional released (but fairly small) application, over 6 months manual intervention was only required on my part 4 times - 3 of which were standard easy merges that simply overlapped in the files, 1 of which was actually a codeveloper and me making incompatible changes due to bad communication. In the one, the SVN system worked perfectly, alerting me to the problem before it ever got commited.