ABOUT some final thoughts
authorTony Finch <dot@dotat.at>
Thu, 27 Nov 2014 15:50:12 +0000 (15:50 +0000)
committerTony Finch <dot@dotat.at>
Thu, 27 Nov 2014 15:50:12 +0000 (15:50 +0000)
ABOUT.html

index ea8a8b8..ef62ab1 100644 (file)
@@ -282,10 +282,10 @@ clean. So the overall uplift process goes through several phases:</p>
 </ol>
 
 <p>For the ip-register directory tree, the pre-uplift phase also
-includes ipreg-archive-fixup which I described earlier. Then in the
-mid-uplift phase the combined histories are rcsappended into the
-proper place in the CVS repository so that their history is recorded
-in the right place.</p>
+includes ipreg-archive-uplift which I described earlier. Then in the
+mid-uplift phase the combined histories are moved into the proper
+place in the CVS repository so that their history is recorded in the
+right place.</p>
 
 <p>Similarly, for the tarballs, the pre-uplift phase unpacks them in
 place, and moves the tar files aside. Then the mid-uplift phase
@@ -305,7 +305,7 @@ The <a href="https://git.csx.cam.ac.uk/x/ucs/ipreg/sccs2rcs2cvs2git.git/blob/HEA
 script produces a list of user IDs as a starting point for an authors
 file.</p>
 
-<h2>cvs2git</h2>
+<h2>Uplifting cvs to git</h2>
 
 <p>At first I tried <tt>git</tt> <tt>cvsimport</tt>, since I have
 successfully used it before. In this case it turned out not to be the
@@ -321,7 +321,7 @@ and fairly soon I had a populated repository: nearly 30,000 commits at
 fast-import/export format allows you to provide file contents in any
 order, independent of the order they appear in commits. The fastest
 way to get the contents of each revision out of an RCS file is from
-newest to oldest, so that it what cvs-fast-export does.</p>
+newest to oldest, so that is what cvs-fast-export does.</p>
 
 <p>There are a couple of niggles with cvs-fast-export, so I have a
 <a href="https://git.csx.cam.ac.uk/x/ucs/ipreg/sccs2rcs2cvs2git.git/blob/HEAD:/cvs-fast-export-1.26.patch">patch</a>
@@ -329,9 +329,34 @@ which fixes them in a fairly dumb manner (without adding command-line
 switches to control the behaviour):</p>
 <ul>
   <li>In RCS and CVS style, cvs-fast-export replaces empty commit
-    messages with &quot;*** empty log message ***&quot;, whereas I
-    want it to leave them empty.</li>
+    messages with
+    &quot;***&nbsp;empty&nbsp;log&nbsp;message&nbsp;***&quot;, whereas
+    I want it to leave them empty.</li>
   <li>cvs-fast-export makes a special effort to translate CVS's
     ignored file behaviour into git by synthesizing a .gitignore file
     into every commit. This is wrong for the ip-register tree.</li>
+  <li>Exporting the hosts.131.111 file takes a long time, during which
+    cvs-fast-export appears to stall. I added a really bad progress
+    meter to indicate that work was being performed.</li>
 </ul>
+
+<h2>Wrapping up</h2>
+
+<p>Overall this has taken more programming than I expected, and more
+time, very much following the pattern that the last 10% takes the same
+time as the first 90%. And I think the initial investigations -
+before I got stuck in to the conversion work - probably took the same
+time again.</p>
+
+<p>There is one area where the conversion could perhaps be improved:
+the archived dumps of various subdirectories have been converted in
+the location that the tar files were stored. I have not tried to
+incorporate them as part of the history of the directories from which
+the tar files were made. On the whole I think combining them, coping
+with renames and so on, would take too much time for too little
+benefit. The multiple copies of various ancient scripts are a bit
+weird, but it is fairly clear from the git history what was going
+on.</p>
+
+<p>So, let us declare the job DONE, and move on to building new DNS
+servers!</p>