View this PageEdit this PageAttachments to this PageHistory of this PageHomeRecent ChangesSearch the SwikiHelp Guide
Hotspots: Admin Pages | Turn-in Site |
Current Links: Cases Final Project Summer 2007

2006Spring: MusExMachina: Cases: Team Productivity Practices: Commit Policy

Concurrent Versioning in Squeak

Our group decided that it would be beneficial to use a concurrent versioning system for our project code. The most readily available system for use in Squeak is Monticello. Monticello is an optimistic concurrent versioning system. Optimistic concurrency control decreases the likelihood of conflicts during a merge, but the user won't know about them until they occur. For notes on how to get started in Monticello, and our recommendations on how to setup a repository, read here: (http://coweb.cc.gatech.edu/cs2340/5369)

In Monticello & Squeak, conflict detection and resolution when merging code is fairly robust. When a conflict occurs it still needs to be resolved, and this consumes valuable programmer time. It is also possible to lose a groupmate's code if one does not merge/commit properly in Monticello. Resolving these issues proved to be time consuming, so our group was forced to minimize the amount they occurred. To this end, we drafted a fairly comprehensive set of submission rules, the ideology behind which can be applied to any versioning system.

"Merge Before Commit!"

Because Monticello does not require it, we did. We wanted to have a single branch incrementally developed as we worked on it and comitted code. When using Monticello is possible to commit versions of your code that don't include all the code currently in the repository. Thus to acheive our goals as a group we mandated that before comitting code to the repository everyone had to ensure that all the code comitted between the last commit/checkout (point in time when the copy on their local machine was current) and when they were comitting was listed as an ancestor.

Version Naming

Monticello's version auto naming system is fairly robust and useful, however we ran into some issues that were eliminated by changing our naming policy for the monticello versions. The version number of the package was incremented per-author which decreased the readability of the progression of the repository (some of us comitted way more often than others, so some commits that were equivalent in functionality had vastly different version numbers. As a result the mandate was that for each commit the version number should be the highest ancestor version + 1. This gave us easily readable versioning, each commit was 1 higher than the previous, giving us a nice distinct timeline of changes in the monticello browser.

Lessons to Take to Other Versioning Systems


Our experience using Monticello crystallized our understanding of what we needed from our versioning system, and a good submission policy can solve many if not all of the needs for a project. The versioning system being used should be evaluated, and any shortcomings (as far as fitting the project requirements) can be patched up with the code submission policy. The system as a whole should ensure that:

  1. Code is never lost, this frustrates group members and lowers their morale (how would you like it if your code disappeared?).
  2. Submissions never "break" the code repository. Two things to watch out for are compilation-time breaking, and run-time breaking. Compilation breaking was not a problem on our project because it is impossible to save "non-compiling" squeak code in the first place, which means it is impossible to commit. With fairly thourough pre-commit testing it is possible to drastically reduce breaking the repository at the level of runtime.
  3. All code should be cleanly documented and organized. Thourough documentation makes the collaboration easier, this should go without saying. It is highly beneficial to have your code commented before it becomes available to the rest of the group, even if it is not finalized or complete. Once they have access to it they will potentially start looking at it, and time will be wasted if it is not readable (uncommented).

Any submission policy should focus on eliminating these potential problems while minimizing the extra overhead for the memebers of the team.

Link to this Page