This shows you the differences between two versions of the page.
Both sides previous revision Previous revision Next revision | Previous revision | ||
geda:version_control_migration [2007/04/21 10:48] peterb Instructions for installing git on Linux |
geda:version_control_migration [2012/02/20 15:14] (current) |
||
---|---|---|---|
Line 1: | Line 1: | ||
+ | ====== 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: | ||
+ | |||
+ | - 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 [[http://www.cobite.com/cvsps/|cvsps]]. | ||
+ | - Merging with CVS is painful, especially when there is keyword expansion brokenness such as the ''Log'' keyword. | ||
+ | - CVS doesn't support renames preserving history. | ||
+ | - The overhead involved in creating and managing a branch in CVS is such that people tend to do one of the following: | ||
+ | - Don't bother | ||
+ | - Use another VCS locally, then export patches, then commit patches to CVS. This is a big hassle for everyone. | ||
+ | - Do II. **and** use a branch in CVS, which is even more hassle, but means people can see the changes in advance. | ||
+ | - 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: | ||
+ | |||
+ | - Free as in beer as well as free as in speech. | ||
+ | - Actively developed/maintained. | ||
+ | - Atomic commits (a.k.a. changesets). | ||
+ | - All users have their own copy of the history. | ||
+ | - Users can make local branches/commits without being logged onto a remote server ("distributed" repository model). | ||
+ | - Merge & rename tracking. | ||
+ | - Easy to transition to from CVS. | ||
+ | |||
+ | Using the [[http://en.wikipedia.org/wiki/Comparison_of_revision_control_software|comparison matrix at Wikipedia]], it looks like only [[http://www.selenic.com/mercurial/wiki/|Mercurial]] and [[http://git.or.cz/|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). | ||