Many of the software projects developed today use distributed and collaborative development environments. Using geographically distributed team vendors are able to achieve ‘24/7 active’ development of their software. It has its own list of challenges and there are tools aplenty to address those challenges in both OSS and commercial category. Here we discuss one of such peculiar problem (i.e, managing concurrent changes to code base) and explain how Eclipse + CVS combination addresses it effectively.
Due to concurrent changes to the code and improper version control process (or lack of sincerity from developers) we almost always land up in ‘conflict’ situations and spend extra effort in resolving them. Below I discuss a process that helped me in a large development project while allowing me to just work with my development IDE. No extra tools required.
- CVS Features for managing concurrent change:
CVS provides various sets of features to help the users manage concurrent change effectively. These features work hand-in-hand to help the team. Some of these features are:
- The “watch” feature: To utilize this feature the user explicitly expresses interest in change (edit/un-edit/commit) in a particular resource. CVS takes care of notifying the user whenever any user executes an operation of his interest on the resource viz. edit/un-edit (as explained below) and commit. This feature is not supported by the Eclipse’s VCM (Versioning and Configuration Management) modules’ CVS implementation as in Eclipse 2.1.
- The “edit” feature: Typically any resource that needs change can follow any of the following paths under CVS:
The alternate paths (IIa and IIb) are also supported by CVS and provide another mechanism to manage concurrent change.
If every user religiously follows path II to issue a “cvs edit” before (s)he starts work on a resource and then issues a “cvs commit” or a “cvs unedit” when work is respectively finished or needs to be rolled back, then CVS can keep track of all current “editor(s)” of a resource.
This conversely gives any other user who wants to work on the same resource an opportunity to check with CVS as to the current “editor(s)” of the resource and take appropriate steps. So the modified path II now becomes,
2. The Eclipse Value-Add:
Eclipse goes a step further to help you achieve this. Under Eclipse, a project can be set to send automatic “cvs edit” commands to the CVS repository whenever a resource is changed / “edit”-ed by a user. All resources for such a project get checked-out as “read-only”. When an actual change is made to the file from within Eclipse, Eclipse switches off the read-only flag and send the “cvs edit” command to the repository.
The story doesn’t end there! Eclipse goes even further. If it so happens that the file being “edit”-ed already has registered editors, Eclipse gives you a “warning” stating who is currently changing the file!!
As such both the manual steps of Path II viz. checking the “editors” of the resource and issuing the “edit” command are automatically taken care-of by Eclipse. All you need to ensure is that you work under Eclipse and respect the warnings – that’s all!!
3. What You Need to Do
- Ensure that eclipse is setup to use edit and watch features.
- Make sure that all files are edited under Eclipse
- IFF (and that should not usually be necessary since Eclipse has editors for almost everything!) you do change anything outside Eclipse, make sure to send an explicit “cvs edit” command from Unix / WinCVS / Eclipse itself!
- When Eclipse warns, don’t ignore. Consult with the existing “editor”.
PS: Special thanks to Sumit Sachdev for his contributions to this article.