SCM Requirements

From Apache OpenOffice Wiki
Revision as of 12:36, 16 January 2007 by Hr (Talk | contribs)

(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to: navigation, search

The problem

CVS has been an invaluable SCM (Software Configuration Management) tool for the past 6 years for OpenOffice.org, but it's showing its age. There have been calls to replace it with a modern SCM solution. The stated reasons vary, but the following topics are mentioned most often:

Branching and tagging is an O(n) operation
OpenOffice.org CWS (Child Workspace) development model relies on heavy use of branches and tags. CVS branching and tagging scales with the number of files affected and is so slow that it actually hinders development for a project of the size of OpenOffice.org.
Versioned renaming of files and directories
A history preserving renaming/moving of files is awkward in CVS, a renaming of directories is plain impossible.
Proper handling of binary files
The CVS way to handle binary files is clumsy and prone to errors.
Atomic commits
CVS has no atomic commits, something which practically all modern SCM have. Interestingly, I never felt that the missing atomic operations are a problem for "commit" operations, but they are badly needed for tagging and branching. It's quite common that a tag run is interrupted (for example during "cwsadd") and than the repository has to be cleaned before the operation can be retried.

Development model

Within the child workspace development model every development is done in private branches. That way a change can be developed and QAed completely insulated from changes in the trunk. In the SCM literature these kind of branches are also called "feature branches". The CWS tools provide means to update the branch to a newer version ("milestone") of the trunk, release engineering is responsible for the integration (merging) of the branches into the trunk. There seems to be an universal agreement that this model is a good model for OpenOffice.org, no one wants to go back to the bad old days of everyone committing directly to the trunk or a release branch. We just need a tool that is better in supporting this kind of development model than CVS.

There is much more to the CWS development model than just the branches and their handling, but this is outside the scope of the SCM system.

Personal tools