Version:	f2c05a6ad279c0cb0c7249b9ff0cea12d9153bf6
Date:	2008-03-14 21:06:47
Original User:	aku
Commands:	history | raw-text

Spiritual ancestor: cvs2svn.

Similarities:

• Using identical highlevel architecture (pass-based)
• Using some specific algorithms (graph traversal).

Differences:

• Not using any of its code (Different languages for one thing, Python there, Tcl here).
• Persistent state completely different, using sqlite database for all things we wish to keep between passes.

Status:

Pass	Description	Notes
CollectAr	Collect archives	Ok
CollectRev	Collect revisions, tags, branches (file level)	Ok
CollateSymbols	Collate symbol (project level) from the file level data	Ok
FilterSymbols	Filter symbols, exclude symbols and lines of development	Ok
InitCsets	Create initial changesets	Ok.
CsetDeps	Compute changeset dependencies from revision dependencies	Ok
Pass BreakRevCsetCycles	Break cycles among revision changesets	Ok
RevTopologicalSort	Topologically sort revision changesets	Ok
BreakSymCsetCycles	Break cycles among symbol changesets	Ok
BreakAllCsetCycles	Break cycles over all changesets	Ok. (Accepting that it may still change the order of revision changesets over the result of pass 7).
AllTopologicallSort	Topologically sort all changesets	Ok
Import	Import files	Ok.
Import	Import changesets	Ok.
Import	Import finalization (fossil rebuild)	Ok.

Notes regarding the actual import:

• 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.
• We can do better, if we get help from fossil. We would need commands to perform the following actions:
  • Import a file as blob, return its internal id.
  • Deltify a known file respective to a second known file.
  • Generate a manifest file for a list of files (paths, ids), parent manifest references, user, timestamp, log message. Could be signed or not.
  
  With these actions (possibly 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.
  Currently I am thinking about wanting a command

  fossil import-files SPECFILE
  

  which imports and deltifies files as blob per the SPECFILE, returning on stdout the associated of paths and internal ids. Example SPECFILE:

  F path1
  D path2 path1
  ...
  

  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.
  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.
  To import manifests we need second command, which generates it from changeset data, and imports it too.

  fossil import-manifest user timestamp MESSAGEFILE FILEFILE parent...
  

  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.
  Note: We have already commands for the put and deltify operations, albeit undocumented, in the set of test commands.

Miscellaneous:

• Add option to allow diverting the log output into a file, except for the progress reporting. Result is nice interactive log + progress, and a (relatively) small log file without all the unwanted progress numbers.
• Go over the SQL statements and check that they have good query plans
• Go over the SQL statements and add comments where they are non-trivial.
• Currently some passes take quite a bit of time when their actual operation is already complete. It seems that sqlite is heavily working on committing a lot of changes (Most passes are wrapped into a single transaction). Consider ways of speeding this up.
  • Do our own transaction management? So that we can commit every X changes?.
  • Should we disable synchronous operation? The state database is not that critical, i.e. it can always be regenerated. On the other hand, being able to be sure that we can restart from the interrupted pass is nice, and not possible if we got it corrupted by asynchronous operation. Tabled for now, this is not yet critical