[Monotone-devel] RFC: CVS sync design

[Christof Petig]

Here is the current design I intend to realize to get CVS sync working:

Goals:
synchronize a monotone database and a CVS repository over a cvs server 
command at least as efficient as a cvs update/commit cycle would do 
[minimize network traffic]. Do not store state information in both trees 
 so that syncing with several CVS servers is possible. Preserve 
changelog and timestamp of every change. Do not try to fully synchronize 
the history but make monotone and cvs agree on a possible head of the 
selected branch. [see below for the multiple head issue]

syntax:
monotone pull [--branch foo] cvs://localhost/usr/local/cvsroot 
module[:branch]

this most closely resembles current monotone standards and should mean:
take CVSROOT "localhost:/usr/local/cvsroot" (via CVS_RSH) [which covers 
95% of my uses] and import the (branch "branch" of) module "module" into 
monotone branch "foo". I'm not quite sold to this syntax, it simply 
seemed most similar to the existing sync/commit syntax. Standard for cvs 
branch is "HEAD", for a _reasonable_ standard for the monotone branch I 
have no idea. Perhaps "module:branch" (which is nonstandard for 
monotone) though localhost.usr.local.cvsroot.module.branch would more 
adherent to current policies.

pull:
Issue an rlist -Red on the server and note the current state [current 
cvs-manifest*], the highest timestamp is the timestamp of the latest 
commit. Get it's changelog [and a list of branches] via rlog 
-rlatest_revision file.

Now look whether a matching revision (timestamp+changelog) is found in 
the monotone database. [Optionally compare every file of the cvs 
manifest and the monotone manifest by checksum (I don't know yet how to 
get a checksum without a patch from cvs (update gives patch and 
checksum), perhaps I can trick update to tell me the (md5) checksum of 
an existing RCS revision by asking for updating a head revision)]

If no matching revision is found go back in history (rlist (RCS revision 
by date) or rlog (changelog by date/revision)) [building it on the fly].
>how to _most_efficiently_ get the full set of recent commits for every 
file?< [Perhaps: take the latest timestamp and ask for the version 
before (with log), take the second latest timestamp and repeat] Repeat 
until we find a matching cvs-manifest and monotone revision (see above). 
Go forward in history and (request the patch(es) for every cvs-manifest 
 and commit to monotone) until we reach the head.

The push command will be an alias to sync because to check into a CVS 
repository you need to have an up to date copy of it. [As we surely all 
know ;-)]

push/sync:
Take the latest monotone revision matching the latest cvs-manifest and 
try to go forward from there (unless we reach a point where two 
descendants are valid). Commit the resulting manifest (asking the CVS 
server for patches).

Once we reach a fork point where multiple descendants are valid present 
the user the descendants in a heads like manner and ask him to specify 
which fork to take for head (using an option to the next sync command)

   Christof

----

* cvs-manifest:
 a timestamp, a changelog and a list of (files and their corresponding 
RCS version number).
cvs-manifests are addressed by their (fuzzy) timestamp and changelog 
[and perhaps author]. Once sorted by their timestamps they should form 
the ancestry graph of the particular cvs branch.

signature.asc
Description: OpenPGP digital signature