Distributed Version Control at the DSS Evaluation Phase

This post will give some insight into the distributed version control ad the Distributed and Self-organizing Systems Group. Usually, I am keen about trying out new things, e.g. distributed version control systems such as GIT, Mercurial or Bazaar. However, currently the group’s infrastructure is set up with Subversion as internal revision control system.

For the next few months we will start an evaluation phase with the students, working on the WebComposition/DGS approach, based on a distributed version control concept. Core components of the WebComposition project are branched into a dedicated student branch where all students can commit changes. Based on this branch each student creates his or her private branch for local changes.

The coordinator (usually some DSS staff) takes care of regular forward integration of the core components into the student branch. Each student in turn is responsible for forward integration into his or her own branch.

Changes can be submitted after testing and evaluation back into the central student branch by each student performing backward integration. The group working on the project has to agree in the LAKS meeting on the change before backward integrating the updates.

The coordinator finally takes care if these changes are also backward integrated into the original project trunk.

Distributed Version Control at the DSS

Step 1: Create a local working copy

First, look for a place where to checkout the working copy. Create a folder, e.g. branchesstudents and use Tortoise to checkout a working copy.

Initial Checkout

Select the student branch and the local folder where to store the working copy to start the checkout.

Branch

After the checkout is finished, you should will have a local working copy of the student branch.

Checkout Complete

Step 2. Create a private branch

Select ‘Branch/tag’ from the context menu of your working copy.

Branch

Use the path of your private project within the repository to create the branch.

Copy (Branch/Tag)

Step 3: Forward integrate changes from the student branch

When the student branch was updated you might be interested in getting these updates into your private branch. To forward integrate these changes into your private branch, select the folder where your local working copy lives, and use the Tortoise context menu to select ‘Merge…’.

Merge Branches

Select the repository folder you want to forward integrate Probably this will be the student branch – the paths in the screenshot below will thus differ from yours. Select the revision from where the forward integration should start. Now select the revision where it should end. Usually, this will be the head revision. After merging submit the changes of your working copy to the repository and you are done.

Merge

To get some more information on Subversion, or to learn how to perform the steps above on command line, refer the Subversion book.

0 thoughts on “Distributed Version Control at the DSS Evaluation Phase

  1. You should definitely try Mercurial, it’s the best of those shiny new revision control systems I tried. Git is like anything that’s been designed by Linus Torvalds: Reinvented the wheel badly, geeky and hard to use. It’ll take lots of hackers better than him to clean it up. Bzr is just too slow.

    BTW, I read a blog posting the other day where one of the svn lead developers pondered about stealing Mercurial’s repository format because it’s much better than what they have.

    The big disadvantage is tool support. Nothing can beat the widespread high-quality support of CVS and Subversion. The Mercurial eclipse plugin, for example, is still in its infancy.

  2. The cool thing about Mercurial is that you don’t need fancy infrastructure. See the unofficial Mercual handbook.

    In your scenario, you could clone the main repository to create the students branch. Then set up a read-only server that serves the students branch using "hg serve" (that’s how it looks, all you need is a shell account). Students clone the student branch, make local changes and submit them in patch format to the coordinator.

    Disclaimer: I’ve only used Mercurial in a purely local, single user environment so far.

  3. Unfortunately, I am not the one maintaining the server. If it’s about me, I am keen o try out everything new. As it is in every ‘large’ team, there are several projects hosted in our version control system and this decission is at the end not on my own. Anyway, maybe it will be part of a future student project to set up an experimental Mercurial server for testing and evaluating distributed version control within the group.

Leave a Reply