views:

71

answers:

2

Our code is in SVN. We develop using Visual Studio and the AnkhSVN plugin.

Having used VSS before SVN I was used to the idea of locking files so other users know not to edit it while you are (in fact I thought this was the main point of source control, to prevent lost data from these conflicts).

I've been told this rarely happens and cases where you can't work because another dev is locking you out are more frequent (which sounds like a principle that might only apply to a certain subset of dev projects). But anyway, SVN is better and we're using it.

So when I do edit a file, and go to check it on, and find out the other user has edited it too, what do I actually do?

Surely there's a better way than saving a copy of my file, reverting changes, updating it from server, then merging my changes back in with winmerge? When I right-click the file and click 'merge' I'm told I should update first, so that's obviously not what I need.

.

Update: partial answer
OK, it sounds like I just hit update, then SVN merges non-conflicting changes automatically, and should let AnkhSVN know about any conflicting changes to allow some kind of resolution. Does anyone know how this works in AnkhSVN - what I'd actually do?

(if not I'll try it myself, accept the current top answer and update this question with the second half for posterity).

+5  A: 

Actually, that's exactly what you need.

Edit: Clarification, what you need to do is just hit that update. You don't need to make a separate copy, revert, etc. Updating from the repository will merge those changes with your own.

When you do the update, where you have local changes to a file that has also been changed in the repository, SVN will merge the file in the repository with your local file, preserving both sets of changes.

In effect, it should do what you would do with Winmerge automatically.

If the changes are conflicting, typically that they occur within the same lines, there will be a merge conflict, which has to be resolved. Not knowing AnkhSvn, I don't know what it will do in this case, but it should have some means of fixing things. Usually it involves looking over 3 files (your local file, the repository file, and the result of a successful merge) where you pick each part you want to keep from the two changed versions of the file.

After you've updated your local copy, merged and fixed any conflicts, you commit as usual.

Lasse V. Karlsen
In my experience there are some files that are prone to merge conflicts, like sql scripts or language localization strings files. In those files we set the svn:needs-lock subversion property. This will force developers to exclusively lock the file before editing, and no one will be able to edit it meanwhile.From Ankh svn you should be able to right click the file an edit subversion properties.
iCe
Yes, you're right, there are indeed files that are prone to merge conflicts for minor edits. Form designer files comes to mind in .NET/C# for instance, where a minor edit can rearrange a lot of code.
Lasse V. Karlsen
@Lasse, I know what you mean, but I think it should be more obvious from your answer that there's no need to manually save your changes elsewhere, revert, update, and manually merge back. Just hitting update is all that's required.
Sander Rijken
Ok, edited answer.
Lasse V. Karlsen
A: 

It´s not an direct answer to your question, but I would recommened to use SVN-Monitor in addition to AnkhSVN or any other Subversion client like TortoiseSVN.

With it you can watch your repository and will be notified by changes in your repository. So you can see what other devs did in the repository and probably see if your commit will conflict with other checkins or if you can update your local copy without any effect/conflict

Jehof