<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd"> <html> <head> <title></title> <link rel="stylesheet" media="screen" type="text/css" href="./style.css" /> <link rel="stylesheet" media="screen" type="text/css" href="./design.css" /> <link rel="stylesheet" media="print" type="text/css" href="./print.css" /> <meta http-equiv="Content-Type" content="text/html; charset=utf-8" /> </head> <body> <h1 class="sectionedit341"><a name="version_control_migration" id="version_control_migration">Version Control Migration</a></h1> <div class="level1"> </div> <!-- EDIT341 SECTION "Version Control Migration" [1-41] --> <h2 class="sectionedit342"><a name="status_quo" id="status_quo">Status Quo</a></h2> <div class="level2"> <p> Currently, gEDA uses <acronym title="Concurrent Versions System">CVS</acronym>. <acronym title="Concurrent Versions System">CVS</acronym> is the “original” version control system used for collaborating on open source projects. </p> <p> Unfortunately, <acronym title="Concurrent Versions System">CVS</acronym> has a number of problems: </p> <ol> <li class="level1"><div class="li"> <acronym title="Concurrent Versions System">CVS</acronym> does not support the concept of patch sets. That is, it's very difficult to work out what changes went into <acronym title="Concurrent Versions System">CVS</acronym> together without using dodgy tools like <a href="http://www.cobite.com/cvsps/" class="urlextern" title="http://www.cobite.com/cvsps/" rel="nofollow">cvsps</a>.</div> </li> <li class="level1"><div class="li"> Merging with <acronym title="Concurrent Versions System">CVS</acronym> is painful, especially when there is keyword expansion brokenness such as the <code>Log</code> keyword.</div> </li> <li class="level1"><div class="li"> <acronym title="Concurrent Versions System">CVS</acronym> doesn't support renames preserving history.</div> </li> <li class="level1"><div class="li"> The overhead involved in creating and managing a branch in <acronym title="Concurrent Versions System">CVS</acronym> is such that people tend to do one of the following:</div> <ol> <li class="level2"><div class="li"> Don't bother</div> </li> <li class="level2"><div class="li"> Use another VCS locally, then export patches, then commit patches to <acronym title="Concurrent Versions System">CVS</acronym>. This is a big hassle for everyone.</div> </li> <li class="level2"><div class="li"> Do II. <strong>and</strong> use a branch in <acronym title="Concurrent Versions System">CVS</acronym>, which is even more hassle, but means people can see the changes in advance.</div> </li> </ol> </li> <li class="level1"><div class="li"> You can't do anything in <acronym title="Concurrent Versions System">CVS</acronym> (view logs, view “blame” for a line of code, create diffs to previous versions) without being online & connecting to the repository.</div> </li> </ol> </div> <!-- EDIT342 SECTION "Status Quo" [42-1144] --> <h2 class="sectionedit343"><a name="what_we_need" id="what_we_need">What We Need</a></h2> <div class="level2"> <p> 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. </p> <p> The following features would be deemed desirable in a version control system: </p> <ol> <li class="level1"><div class="li"> Free as in beer as well as free as in speech.</div> </li> <li class="level1"><div class="li"> Actively developed/maintained.</div> </li> <li class="level1"><div class="li"> Atomic commits (a.k.a. changesets).</div> </li> <li class="level1"><div class="li"> All users have their own copy of the history.</div> </li> <li class="level1"><div class="li"> Users can make local branches/commits without being logged onto a remote server (“distributed” repository model).</div> </li> <li class="level1"><div class="li"> Merge & rename tracking.</div> </li> <li class="level1"><div class="li"> Easy to transition to from <acronym title="Concurrent Versions System">CVS</acronym>.</div> </li> </ol> <p> Using the <a href="http://en.wikipedia.org/wiki/Comparison_of_revision_control_software" class="urlextern" title="http://en.wikipedia.org/wiki/Comparison_of_revision_control_software" rel="nofollow">comparison matrix at Wikipedia</a>, it looks like only <a href="http://www.selenic.com/mercurial/wiki/" class="urlextern" title="http://www.selenic.com/mercurial/wiki/" rel="nofollow">Mercurial</a> and <a href="http://git.or.cz/" class="urlextern" title="http://git.or.cz/" rel="nofollow">git</a> have the features we require. </p> <p> A number of factors militate in favour of using git: </p> <ul> <li class="level1"><div class="li"> Existing experience within the the gEDA development community.</div> </li> <li class="level1"><div class="li"> More extensively used by major projects (Linux kernel, X.org X server, OLPC, WINE).</div> </li> </ul> </div> <!-- EDIT343 SECTION "What We Need" [1145-] --></body> </html>
distrib
>
Mageia
>
5
>
x86_64
>
media
>
core-release
>
by-pkgid
>
f2f28f61487f3042d93877451f0a311f
>
files
>
262
