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.
- 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.
- Work with the files you are interested.
- 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.
- Now you are ready to check-in code into CVS. do synchronization.
- If the synchronization results in incoming files update your system with them. For conflicts, resolve the conflict thru the ‘manual’ merge process.
- Compile the code and ensure it compiles clean.
- Do synchronize again.
- 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.
- Avoid using the “Override and Commit” and “Override and Update” commands unless you are an experienced developer.
- Do synchronization multiple times in a day. This will keep you closer to latest code and reduce the need for code merge.
- 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.
- You should make it a habit to check-in all your code/docs into CVS before you leave office everyday.
- Your code must compile clean before doing any check-in.
- 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.