Dealing with conflict in SVN

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.

Commit

image

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 :

image

Update

image

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

unchanged

updated
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

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.

image

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.

image

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.

image

Once you are happy with the merged version, you can safely mark the file as resolved (image ). Now you can confidently commit your changes.

PS : For a more comprehensive guide on SVN conflict, you can go here.

Advertisement

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s