@@ -21,11 +21,11 @@
   *  Pass BreakACycle: Break cycles over all changesets - <b>May still change the order of revision changesets over the result of pass 7.</b>
   *  Pass ATopSort: Should be ok.
 
 Passes to do:
   *  Put changeset order from the top.sort passes and tree of symbols from the coll|FilterSym passes together into a tree of changesets. Note that it might not be a tree if there is an NTDB around.
-  * Perform the actual import.
+  *  Perform the actual import.
 
 Notes regarding the actual import:
 <ul>
 <li>cvs2svn is either slow, or hungry for diskspace. The reason: It is importing changeset by changeset and so has to either regenerate the needed revisions of the files on-demand over and over, or it caches the needed revisions when created until the last user is gone.
 </li>
@@ -36,8 +36,31 @@
 <li> Deltify a known file respective to a second known file.
 </li>
 <li> Generate a manifest file for a list of files (paths, ids), parent manifest references, user, timestamp, log message. Could be signed or not.
 </li>
 </ul>
+<br>
 With these actions (possible in combination) we can import the archive files first, needing only space for the revisions of a single file (bounded by the largest file in terms of size and history), with their delta-links mirroring the RCS structure. After that we can independently generate, import, and deltify the manifests for changesets. to finalize we simply 'rebuild' the repository. This should be fast without needing much temporary disk space either.
+<br>
+Currently I am thinking about wanting a command
+<pre>
+fossil import-files SPECFILE
+</pre>
+which imports and deltifies files as blob per the SPECFILE, returning on stdout the associated of paths and internal ids. Example SPECFILE:
+<pre>
+F path1
+D path2 path1
+...
+</pre>
+The 'F' card tells it to import 'path1' as is. The 'D' card then tells it to import 'path2' as is and then deltify 'path1' in terms of 'path2'. And so on.
+<br>
+To import an RCS archive we now just have to generate the full revisions in some tempdir, then create a SPEC showing the delta-links and let fossil have this. The resulting ids then go into the importer state for when we generate the manifests.
+<br>
+To import manifests we need second command, which generates it from changeset data, and imports it too.
+<pre>
+fossil import-manifest user timestamp MESSAGEFILE FILEFILE parent...
+</pre>
+The 'messagefile' contains the log message, the 'filefile' lists the revisions in the manifest by id, and with path in the workspace. The parents are the ids of the parent manifests. The result of the command is the id of the new manifest.
+<br>
+Note: We have already commands for the put and deltify operations, albeit undocumented, in the set of test commands.
 </li>
 </ul>