[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Monotone-devel] RFC: CVS sync design
From: |
Christof Petig |
Subject: |
[Monotone-devel] RFC: CVS sync design |
Date: |
Thu, 23 Dec 2004 09:41:36 +0100 |
User-agent: |
Mozilla/5.0 (X11; U; Linux ppc; de-AT; rv:1.7.3) Gecko/20041007 Debian/1.7.3-5 |
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
- [Monotone-devel] RFC: CVS sync design,
Christof Petig <=