In a previous post, a colleague was venting about having to manage the version control system with a commit token. Basically, the token is held by someone while they’re doing there commit, so that no other developer is supposed to commit, and potentially create conflicts. As a number of us are using CVS, this is a real issue. CVS handles each file individually, so it may stop the commit of only 1 file, thus leaving the repository in a broken state.
But this is only one of the reasons for having the commit token. The other major reason is ensuring that developers have tested their code with the latest version in the repository before committing. A process is in place once a developer recieves the token.
- fix conflicts
- run tests
This is done to reduce the chances that broken code ends up in the central repository, thus impacting the other developers, and their productivity.
To reduce queue sizes, various guidelines can be used, such as no retrieving the token unless you’ve recently done an update and run the tests.
Bottom line, it can be managed….. BUT as others have said, is there a better way? Do we need an artificial, external locking mechanism?
The answer would appear to be no, as long as you’re willing to move to a new VCS. Of course, this has it’s own potential issues, but I’m currently spearheading an initiative on my team to start using Mercurialfor our development.
Mercurial is a distributed VCS. It uses atomic commits (Subversion was one of the early implementors of this feature), and tracks renames. It also makes branching AND merging very easy.
Doing a quick experiment, if 2 developers were to commit, one would succeed, and the other would be warned that they’re attempting to create a new head. So, developer 2 would know someone else committed, and that they need to do the update/merge/test/commit cycle. So, theoretically, there would no longer be a need for an explicit commit token.
Even if the token concept is persisted, or I’m waiting for other developers to complete a large commit, I can commit my changes locally, do some more work, do another commit, and then when I’m allowed to ‘commit’ to the central repository, I merely update, test and push.
If I’m in the middle of something, I can shelve my outstanding changes to update/test/push, and then unshelve to return to where I was at.
There are many more advantages of Mercurial, and as my team starts using it next iteration, I’ll keep posting updates.