Version Control for Dummies - part 3

This will be a three part series. Part 1 is aimed at the project leader. It explains why you need version control and how to set it up. Part 2 is aimed at the developer who will need to work with the version control, so covers how to use it. Part 3 is about conflicts and other important topics.

Introduction
The version control is working, its being used ok. This is looking at some of the other features and a very common issue: conflicts.

What is a Conflict?
Take a case when you have two developers 'Fred' and 'Jim' both working on the same set of code.  We will assume they both get copies of the code & work on their machines adding different features.
When it comes times to commit back to the version control, this is when problems occur.

Fred commits first and there is no issue, after all he is working with the most recent copy of the code.

But when Jim want to commit what will happen?

If you are using a shared directory approach, Jim's code will just overwrite Fred's (not good).  Instead, the version control detects that Jim's code was based upon an older copy of the code and will not allow it to happen:

This is known as a conflict.

You can find out a bit more about this using the 'show log' command, and then do a compare your current code against the code stored in the version control.

This will provide a graphics difference comparing the two copies of the code. (Looks complex, doesn't it?)

Resolving the conflict
There are basically 3 ways to solve the conflict:

1. Jim can delete out your own code, then do a update from the version control and replace all his code with Fred's newer copy
2. Jim could move his code out of the way, get an updated copy of the code and try to copy/merge his changes in (good luck)
3. Jim can let the version control system merge the code together (which is hopefully not too painful)

If none of these sound good, thats because they are.  But remember, the alternative was just to blindly overwrite someones else code.

First you need to update the code to get it up to the most recent version (done before, not covered)
You will get a warning message like this:

It warns you that there is a conflict which needs to be resolved.
If you look at your hard disk, you will see a set of files:

The .mine is your original code, the .r4 & .r5 are the other copies of the code (in this case version 4 & 5, you will have other numbers).  The original file will have been replaced by the merged code which looks a bit like this:

If you know how, you can edit this directly and fix the code, but its easier to instead right click and use 'Edit Conflicts' which gets the merge program up.

The code in the top left is the 'most up-to-date' code from the repository.  The code on the top right is 'your code', and the code at the bottom is where you put the merged code.
There are a number of helpful features to make it a little easier:

This allows you to just copy the block of code from one side or the other or have them both.

VITAL: Once you have finished making a merge, load the code back into your compiler and recompile to make sure there are no errors in the code.  Just because it merges, doesn't mean the code is good.

Once the code has been checked, its time to commit the new code to the repository and move on.

Backups
One of the great things about version control systems is it keeps a complete copy of all the code.  But what happens if the server goes down?
If usually possible to backup the repository, here's how to backup an SVN http://stackoverflow.com/questions/2302592/how-do-i-back-up-a-remote-svn-repository

Getting a certain copy of the code
Again another task you might want to do: Get last weeks code.  To do this, just use Checkout, but instead of getting the 'HEAD', you can specify a given revision in the dialog box.

Branches & Merges
Its possible (though I just about never do it). To branch the code off, then you can work on two versions of the code (the main trunk and the branch).
Possible, not required, probably not advisable.

Conclusion
Thats about all I have ever needed to do with the version control systems, and overall it has served me well.
Hope this gives you a good idea of what its all about.

Happy coding,
Mark