Update: We switched to subversion in May 2005: SubversionGuidelines

---

The purpose of this page is to capture the process for switching version control systems.

We are currently using CVS, which has a number of problems:

• CVS is difficult to secure
• CVS makes it difficult to go back to a specific repository state (unless you tag really often)
• CVS's support for branching and merging is not sophisticated to support

Candidates for a new version control system are:

Subversion

Pros

• versioned moves and renames
• global revision numbers and atomic commits make it easy to revert to a particular repository state
• CVS-like user model
• seems to be picking up momentum both among users and tool producers
• Apache module and use of WebDAV make it much more scalable that CVS, and make it easier for people behind corporate firewalls
• Apache module allows variation in methods for authentication
  • important for easily adding committers, also granularity of control is much finer
• Large diverse development community
• Easy to migrate a CVS repository to SVN, while maintaining history
• Supports some disconnected operations, e.g. "svn diff" compares local changes to unmodified, cached copies of checked out files
• Python bindings for scripting

Cons

• facilities for branching and merging are weaker than arch
  • Specifically it doesn't keep track of which which patches have been merged between branches, i.e., "history-sensitive" merging -- the developer is responsible for keeping track of the revisions that have been merged, usually by noting it in the log (Morgen)
• doesn't allow for arch style distributed repositories
  • The downside to this is developers without commit privilege have a hard time participating, whereas with a distributed model anyone can publish their own archives (Morgen)
• uses 2x disk space since it keeps a pristine version of each file you checkout, regardless of whether you are modifying them

Barriers to adoption at OSAF

• lack of good GUI tools (June 2006: no longer true - David)

Arch

Pros

• versioned moves and renames
• very powerful branching and merging facilities
• supports both a centralized and decentralized repository model
• tools for interoperating with a CVS system

Cons

• current command line tools are fairly complicated
• not widely adopted
• small development community
• If we do want a central official repository that developers commit to, it seems like there are hoops to jump through. I don't believe we want a model where there is a single gatekeeper that is the sole owner/committer of the central repository.
• Arch creates filenames beginning with + and = which confuse the heck out of zsh and vi

Barriers to adoption at OSAF

• lack of good GUI Tools
• poor support for windows

Criteria for making a decision

• One of the candidates achieves good GUI tools (ala SmartCVS^?)
• ...

-- TedLeung - 21 Jul 2004

---

Web tool integration? LXR is easy - anything that I can check out I can put into LXR. Bonsai is hard, since it works directly on a CVS repository (the ,v files). There is an "svn_bonsai" but it did not seem to have the features or the UI that I crave from Bonsai.

-- HeikkiToivonen - 22 Jul 2004

---

Two SVN web tools I have tried are WebSVN and ViewCVS+SVN (those links take you to my installation which has a copy of chandler converted to SVN).

Also, be sure to read this review of Subversion and Arch: http://www.dwheeler.com/essays/scm.html

-- MorgenSagen - 24 Jul 2004

---

So what do I "crave from Bonsai" that other tools don't seem to provide?

• The querying capability as presented here: http://bonsai.osafoundation.org/cvsqueryform.cgi
  • The report format from query, for example last week
  • "Show commands that could be used to back out" - maybe backing out is easier with svn and I wouldn't need this?
• "blame annotated view of source", for example: http://bonsai.osafoundation.org/cvsblame.cgi?file=chandler/application/Application.py&rev=1.254&root=/usr/local/cvsrep

-- HeikkiToivonen - 26 Jul 2004