User Tools

Site Tools


geda:version_control_migration

Version Control Migration

Status Quo

Currently, gEDA uses CVS. CVS is the “original” version control system used for collaborating on open source projects.

Unfortunately, CVS has a number of problems:

  1. CVS does not support the concept of patch sets. That is, it's very difficult to work out what changes went into CVS together without using dodgy tools like cvsps.
  2. Merging with CVS is painful, especially when there is keyword expansion brokenness such as the Log keyword.
  3. CVS doesn't support renames preserving history.
  4. The overhead involved in creating and managing a branch in CVS is such that people tend to do one of the following:
    1. Don't bother
    2. Use another VCS locally, then export patches, then commit patches to CVS. This is a big hassle for everyone.
    3. Do II. and use a branch in CVS, which is even more hassle, but means people can see the changes in advance.
  5. You can't do anything in CVS (view logs, view “blame” for a line of code, create diffs to previous versions) without being online & connecting to the repository.

What We Need

gEDA has a development process that involves a number of people working independently on separate changes. Some of these are a single changeset hacked together in a few minutes, some involve several major changes and are developed over a matter of months. Often, in order to track down a tricky bug, it is necessary for a developer to try and work out what a fellow developer did several months ago.

The following features would be deemed desirable in a version control system:

  1. Free as in beer as well as free as in speech.
  2. Actively developed/maintained.
  3. Atomic commits (a.k.a. changesets).
  4. All users have their own copy of the history.
  5. Users can make local branches/commits without being logged onto a remote server (“distributed” repository model).
  6. Merge & rename tracking.
  7. Easy to transition to from CVS.

Using the comparison matrix at Wikipedia, it looks like only Mercurial and git have the features we require.

A number of factors militate in favour of using git:

  • Existing experience within the the gEDA development community.
  • More extensively used by major projects (Linux kernel, X.org X server, OLPC, WINE).
geda/version_control_migration.txt · Last modified: 2012/02/20 15:14 (external edit)