Version control in Agile development team


Today’s customers and vendors want Agile development practices for every  software project. Wish this could be applied as effectively to non-software projects as well. :) Version control is an important activity of every software project and the success of a project largely depends on effectiveness of the version control process used during the project execution.Though it depends on the maturity and sincerity of the developers too but a successful version control is almost always backed by a strong configuration management “process”.

Here, i will explain the very general approach / process that applies to most of the projects. A tweak here n there is usually done to suit the specific environment. CVS and SVN are the tools of choice for agile development projects. I will not talk about the installation and setup for them. I will assume that its is setup and all developers have the code checked out into their local repositories. Following steps need to be followed religiously by all persons on daily basis to maintain a healthy version control system.

  1. Do synchronization as the first task everyday morning. If the synchronization results in any “incoming” files, get the files into local machine. This ensures that you start with “latest” copies.
  2. Work with the files you are interested.
  3. Once you have finished working on a file, do clear any coding standard violations. Compile it and clear any compilation issues. Clear any compiler warnings.
  4. Now you are ready to check-in code into CVS. do synchronization.
  5. If the synchronization results in incoming files update your system with them. For conflicts, resolve the conflict thru the ‘manual’ merge process.
  6. Compile the code and ensure it compiles clean.
  7. Do synchronize again.
  8. In most of the cases you should now only have outgoing files. In such a case commit those files into CVS with appropriate comments. Otherwise repeat the steps 5 to 8.

General Guidelines

  1. Avoid using the “Override and Commit” and “Override and Update” commands unless you are an experienced developer.
  2. Do synchronization multiple times in a day. This will keep you closer to latest code and reduce the need for code merge.
  3. Do not keep modified code in your local machine. If the code is in a state to compile clean, try to commit it to CVS.
  4. You should make it a habit to check-in all your code/docs into CVS before you leave office everyday.
  5. Your code must compile clean before doing any check-in.
  6. Check-in comments – comments should explain why a change was done. What changes were done can be found from the history, so it needs no mention.

The above process is manufactured out of my development experience. If you have faced any situation which you think applies to version control process in general, please share. 

4 comments

  1. CVS also has an “Edit” feature that I wud highly recommend — esp. the near-transparent manner in which it is integrated into Eclipse. It provides for easy means to keep track of the developers working on a piece of code and co-ordinate to pre-empt conflicts!

    Unfortunately SVN doesnt seem to have it / an equivalent feature nor does there seem to be any plans😦

  2. How do you setup check-in check-out of files using CVS. Right now it allows all of us to check-out a file at the same time. Thanks in advance.

  3. @Brian,
    CVS (and well as SVN) are designed to allow and encourage concurrent access to files by multiple developers.

    If you are coming especially from a VSS / Clearcase kind-of background – this approach might sound very foreign but once you use it you will see the power and flexibility it provides🙂

    I would recommend reading some basic material on CVS (google “CVS Manual”) or SVN (google “SVN Redbook”). Here is one link that might be useful:
    http://svnbook.red-bean.com/en/1.1/ch02.html

    [PS: For the record – CVS/SVN also support the single-check-out model via the concept of “file locking” — and its quite helpful in specific situations too — but would not recommend taking that as the default approach. If you are still not comfortable with concurrent access ( thought there should be no reason why ) – look out for other tools instead !🙂 ]

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 )

Google+ photo

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

Connecting to %s