Collaboration with Revision Control

A group who codes programs without revision control is stupid. And crazy.

Seriously, what self respecting software developer in 2009 in their right mind would use a “shared network folder” approach in sharing code instead of opting for a VCS?!?!

—

Here we come to the second important purpose of revision control, namely, to automate most of the processes involved in sharing work among multiple users. Those processes and the problems involved with them are neatly described in the SVN book. Just click the link and come back here when you’re done reading the chapter (saves me the copy-paste effort :P ).

Now that you’re familiar with the Lock-Modify-Unlock and Copy-Modify-Merge approaches, let’s try to replicate those scenarios in TortoiseSVN. But first, we’ll use VisualSVN Server for our SVN server. Not only does this allow us to abandon the “file:///” URL for the more practical “http://” URL, it also allows other computers in your network to connect to your repository.

Installing VisualSVN Server is easy; just the download the installer and install it just like any other program.

For this tutorial, create a 2 users (eg. Alice and Bob) and a repository in VisualSVN Server Manager (should be straightforward). Give those 2 users Read/Write permissions to the new repository by right-clicking the repository -> Properties -> Security tab -> Add..

Check out the repository into different folders using the two different accounts (there’s a “Copy URL to Clipboard” option when you right click the repository in VisualSVN Server Manager). It’s easier to use two computers here so that you won’t need to type the username/password every time you perform an action; just tick the “Save Authentication” checkbox after entering this data in the Authentication window.

Copy-Modify-Merge scenario 1: conflict can be merged by SVN

Create a sandwich.txt in Alice’s folder containing the following text:

Top piece of bread
Lettuce
Tomato
Provolone
Bottom piece of bread

then update Bob’s folder to receive the new file.

Now let’s make a merge-able conflict. This usually happens when two developer modifies different functions in the same file. Update Bob’s copy to add “Creole Mustard” on top of “Bottom piece of bread” and commit the file (don’t forget to add a message!).

Before updating Alice’s copy, add “Mayonnaise” below “Top piece of bread”.

Now perform the update.

Creole Mustard from Bob is now added to the file. There’s no error message because changes don’t overlap and so SVN can automatically merge the files.

Perform a commit for Alice to add the Mayonnaise to the repository. Update Bob’s copy to add the Mayonnaise to his copy.

Copy-Modify-Merge scenario 1: conflict must be merged manually

Now let’s replicate the problem mentioned in “Merging conflicts by hand” in the SVN tutorial.

Let Bob add “Sauerkraut” and “Grilled Chicken” before Creole Mustard and commit the file to the repository. Before updating her copy, add “Salami”, “Mortadella”, and “Prosciutto” before Creole Mustard in Alice’s copy. Now try to update Alice’s copy.

Oh noes!!! Click OK to continue.

There are now 4 copies of the file:

1. sandwich.txt.mine – your local copy of sandwich.txt
2. sandwich.txt.r(x) – the revision you last checked out before making your edits
3. sandwich.txt.r(y) – the current revision in the repository
4. sandwich.txt – the partially merged file with conflict markers

When you encounter this scenario, the best course of action is to:

1. Review the files and determine the extent of the conflict.
2. If you believe that your changes should overwrite the other person’s changes, talk to the person/s who made the changes and agree upon a course of action.
3. On the other hand, if you believe that your changes should be discarded, simply use the Revert function to use the other person’s copy.

Once you have decided upon a course of action in step 2, you can now merge the conflicts manually as described in the book. An easier approach, however, is by right-clicking the file -> TortoiseSVN -> Edit Conflicts.

The question marks in the bottom panel show the portions which are in conflict. You can right-click the text blocks on either left (theirs) or right (mine) and select the appropriate action. The buttons on the toolbar have the same function.

Following the resolution described in the book will result in the picture above. After saving the file, resolve the conflict by right-clicking the file -> TortoiseSVN -> Resolved.. Since we only have one conflicted file, just click OK to resolve the conflict. This will remove the temporary files and mark the file as resolved, allowing you to commit the file without problems.

Revision Control Advice

Some pieces of advice I’ve learned from almost 5 years of working with CVS:

• As mentioned in the SVN book, use the Lock-Modify-Unlock approach when dealing with binary (non-text) files. In TortoiseSVN this can be done by right-clicking the file -> TortoiseSVN -> Get Lock. The lock is automatically released when you commit the file.
• In contrast, you should never lock a text file unless you have a really good reason.
• VCSs should not replace communication between team members. In other words, never resolve a conflict without talking to the other guy. You’ll just set yourself up for a world of hurt.
• Frequent conflicts are signs that your team is working on a poorly designed system–too many people are working on the same pieces of code. Either you refactor your code to reduce these conflicts, or you modify your team structure so that people know who is responsible for which code.
• Never break the build. A “broken build” means that the current revision in the repository doesn’t work, either via compilation or runtime errors. To avoid this, one must make it a point to Update before Commit:
  1. Update your local copy.
  2. Resolve conflicts, if any.
  3. Test if your copy is working.
  4. Commit your files. (Don’t forget to add the message.)
  5. Update your local copy again and test it (in case someone committed something new between step 1 and 4)
• Commit all of the files you modified instead of just a subset of them. This prevents you from inadvertently breaking the build because you missed committing some files. If committing a subset of your files is needed, e.g. you’re working on fixing 10 bugs at the same time but QA needs a fix for one of those bugs ASAP, follow the steps above but replace step #5 with “Checkout the repository to another folder and test it there.” to prevent breaking the build.