Okay, you have finished working on a cool new feature in your app. It works perfectly on your machine, and you can’t wait to let the world know about it. But first, you should commit your work to the central SVN server so the other team member could see it.
In SVN, you do a commit operation to send your local changes to the central repository. Generally, my rule for commit is to do it as often as I could. Of course, to avoid upsetting the other team member, I must also ensure that the code I commit is compilable.
Why I have to do it frequently, you ask? The rule of thumb is, whoever commit first, wins. If someone happens to commit before you do, instead of the usual success message, you may ends up with something like this :
Ok, because we ‘lose’ in the commit ‘race’, we have to do an update. Just right-click, update. How bad could that be?
You do an update to get the latest version from the central repository, and merge them with your local changes. The result could be one of the following :
no remote changes
|remote changes exist|
|no local changes||
|local changes exist||modified||merged / conflicted|
If you have updated a file, and the server also has changes on the same file, you may be experiencing something called *drum roll please* conflict.
Conflict is the worst thing could happen after an update. It means your local and the server both have changes, and the SVN doesn’t know how to deal with it (if it does, it will be automatically merged).
A conflict basically means SVN asks for your help to merge the changes. In order to assist you resolving the conflict, SVN has kindly insert a conflict marker on the conflicted files. Well, the intention is good, but as the saying goes, the road to hell is paved with good intentions.
In my earlier time working with SVN, I realized that there is an option labeled resolved. I happily click it, and the conflict suddenly gone. The file is now marked as modified, and ready to be included in a commit.
That’s it? Well, if you really look at the content of the file, you’ll realize that it is quite a mess. Your local changes is still there, so are the remote changes from the server, plus the conflict marker inserted by SVN is also there. That is definitely not what I want.
The correct way to handle the conflict is by using the Edit conflicts menu. You’ll see three panes, one for the remote changes (theirs), one for your local changes (mine), and the large one is for the merged version.
Also, on the indicator in the left, look for a red sign. That’s where the conflict is.
You have the option to discard one version, and keep the other, or keep them both in a particular order. Basically, you are in control now.
PS : For a more comprehensive guide on SVN conflict, you can go here.