Handling frequent changes in csproj files with Visual Studio and Ankhsvn

Question

I am using ankhsvn to collaborate with my friend on a project in Visual Studio.

Both of us are making frequent changes to the same project although we do not make changes to the same source files.

I have hard time understanding how to tell subversion to handle the automatic changes VS is making in .csproj and .sln files. As i see it i have two options:

1. include the .csproj file under regular version control, and then each time i update before commit i will get a conflict since my friend has commited before me and done some changes to .csproj file.
2. put .csproj file in the ignore list, and then i will have problems since my project will not contain all the changes my friend had done.

So in both ways i have to either solve conflicts or solve dependencies problems etc.

Is there any easier way to do this ?

Thanks.

Answer 1

I'd like to make a quick suggestion for handling the .sln and .csproj files under svn.

Start by fully updating your project.

Look for a locking mechanism in which you obtain a lock on the file and no one else can commit changes to it. If you use TortoiseSVN like I have, see https://tortoisesvn.net/docs/release/TortoiseSVN_en/tsvn-dug-locking.html

Now quickly add the files normally (add them in the file tree and tell the project to include it).

Then commit the new files along with the edited .sln and .csproj files.

If your svn does not release the lock after committing, release it now.

Now you should be in the clear. You know that the solution and project files work for you. However, they might not work for your friend if he or she edits the .sln or .csproj before updating to your new .sln or .csproj. In this case, he or she will probably have to delete their .sln or .csproj, load yours, and then handle the rest. (I don't know if they'll have to add their files to the solution or project again, or if Visual Studio will do it for them.)

Note that you can add empty files just so that the project is aware of them and commit with this process. That will be quick, so that it is unlikely that anyone else is editing at the same time. You can always edit the file normally afterwards. It shouldn't need content if you haven't written anything to rely on it yet. If the file needs some content so that it doesn't break the solution, then consider giving the file some valid content that you'll replace later.

If anyone has other suggestions, I'd be interested to hear them. However, this post is 3 years old at the moment...

Answer 2

In my experience, #1 is your only option. As both of you are editing the .csproj regularly, and the nature of the .csproj is that both of your changes will always occur in the same region of the file, you're going to have conflicts.

Absolutely avoid #2. I can only think that you'd want to do this because you're worried about resolving conflicts incorrectly, and you find that it will be easier for you to just use "add reference" in VS. I wouldn't do this because most conflict resolution in .csproj files (I am assuming that you're both adding dependencies regularly) amounts to using "use mine before theirs" or vice versa in TortoiseMerge. If you're not using a merge tool and are doing it in a text editor, I recommend trying TortoiseSVN so you have an easy way to merge.

Answer 3

I believe your issue is by design. You should not exclude the project file.

Actually the smart way to do this is to separate your code into multiple projects / modules / libraries. In that case your project files may change but since you work in a different one it's not a problem. Everything is kept together in a solution file which only changes if you add / remove projects. Of course this means that you need to plan your software project and define modules before implementing them but thinking before doing is rarely a bad choice.

Edit: You may want to think about a different version control system as well. Something like mercurial or git should help since you only pull / merge the changes that you need.