docs/wiki/geda-version_control_migration.html

   1 <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
   2  "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
   3 <html>
   4 <head>
   5   <link rel="stylesheet" media="screen" type="text/css" href="./style.css" />
   6   <link rel="stylesheet" media="screen" type="text/css" href="./design.css" />
   7   <link rel="stylesheet" media="print" type="text/css" href="./print.css" />
   8
   9   <meta http-equiv="Content-Type" content="text/html; charset=utf-8" />
  10 </head>
  11 <body>
  12
  13 <h1 class="sectionedit1" id="version_control_migration">Version Control Migration</h1>
  14 <div class="level1">
  15
  16 </div>
  17 <!-- EDIT1 SECTION "Version Control Migration" [1-41] -->
  18 <h2 class="sectionedit2" id="status_quo">Status Quo</h2>
  19 <div class="level2">
  20
  21 <p>
  22 Currently, gEDA uses CVS.  CVS is the “original” version control system used for collaborating on open source projects.
  23 </p>
  24
  25 <p>
  26 Unfortunately, CVS has a number of problems:
  27 </p>
  28 <ol>
  29 <li class="level1"><div class="li"> CVS does not support the concept of patch sets.  That is, it&#039;s very difficult to work out what changes went into CVS 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>
  30 </li>
  31 <li class="level1"><div class="li"> Merging with CVS is painful, especially when there is keyword expansion brokenness such as the <code>Log</code> keyword.</div>
  32 </li>
  33 <li class="level1"><div class="li"> CVS doesn&#039;t support renames preserving history.</div>
  34 </li>
  35 <li class="level1 node"><div class="li"> The overhead involved in creating and managing a branch in CVS is such that people tend to do one of the following:</div>
  36 <ol>
  37 <li class="level2"><div class="li"> Don&#039;t bother</div>
  38 </li>
  39 <li class="level2"><div class="li"> Use another VCS locally, then export patches, then commit patches to CVS.  This is a big hassle for everyone.</div>
  40 </li>
  41 <li class="level2"><div class="li"> Do II. <strong>and</strong> use a branch in CVS, which is even more hassle, but means people can see the changes in advance.</div>
  42 </li>
  43 </ol>
  44 </li>
  45 <li class="level1"><div class="li"> You can&#039;t do anything in CVS (view logs, view “blame” for a line of code, create diffs to previous versions) without being online &amp; connecting to the repository.</div>
  46 </li>
  47 </ol>
  48
  49 </div>
  50 <!-- EDIT2 SECTION "Status Quo" [42-1144] -->
  51 <h2 class="sectionedit3" id="what_we_need">What We Need</h2>
  52 <div class="level2">
  53
  54 <p>
  55 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.
  56 </p>
  57
  58 <p>
  59 The following features would be deemed desirable in a version control system:
  60 </p>
  61 <ol>
  62 <li class="level1"><div class="li"> Free as in beer as well as free as in speech.</div>
  63 </li>
  64 <li class="level1"><div class="li"> Actively developed/maintained.</div>
  65 </li>
  66 <li class="level1"><div class="li"> Atomic commits (a.k.a. changesets).</div>
  67 </li>
  68 <li class="level1"><div class="li"> All users have their own copy of the history.</div>
  69 </li>
  70 <li class="level1"><div class="li"> Users can make local branches/commits without being logged onto a remote server (“distributed” repository model).</div>
  71 </li>
  72 <li class="level1"><div class="li"> Merge &amp; rename tracking.</div>
  73 </li>
  74 <li class="level1"><div class="li"> Easy to transition to from CVS.</div>
  75 </li>
  76 </ol>
  77
  78 <p>
  79 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.
  80 </p>
  81
  82 <p>
  83 A number of factors militate in favour of using git:
  84 </p>
  85 <ul>
  86 <li class="level1"><div class="li"> Existing experience within the the gEDA development community.</div>
  87 </li>
  88 <li class="level1"><div class="li"> More extensively used by major projects (Linux kernel, X.org X server, OLPC, WINE).</div>
  89 </li>
  90 </ul>
  91
  92 </div>
  93 <!-- EDIT3 SECTION "What We Need" [1145-] --></body>
  94 </html>