monotone-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Monotone-devel] cvssync per monotone automate (proposal)


From: Christof Petig
Subject: [Monotone-devel] cvssync per monotone automate (proposal)
Date: Sun, 29 Jan 2006 19:35:30 +0100
User-agent: Mail/News 1.5 (X11/20060119)

Hi Nathaniel, hi monotoners,

what do you think about separating cvssync from the monotone core since
I realized that tailor, the git branch and others to come (svn,...) do
only use a small subset of monotone's features. Also for cvssync the
network latency/bandwidth should be the limiting factor, not process
switches or pipe bandwidth.

It would also clean up cvssync's code considerably and might enable
further optimization which transceed my understanding of monotone's
internals (especially the fourth functionality, see below). Also this
would allow cvssync to remain an external contribution.

AFAIK cvssync needs the following features:
- register a file's data (optionally as a delta) [preparing for a future
commit]
- check in a new revision by specifying a parent and a changeset
[preferrably without a workspace]

- issue a certificate [already there]

- find the last synchronized revision [for cvssync this means: find the
latest (either time or (preferred) ancestry) revision which either
changes the synchronization information file ".mt-cvs_revisions" or has
a (after commit attached) delta certificate ("cvs_revisions") *]
- request file contents [already there?]
- request change sets [already there?]
- request manifests (a list of files and contents)

perhaps?
- automatically and transparently handle the file/certificate mechanism
to attach synchronization (cvs manifest=map<file,rcs revision>)
information to monotone revisions
- find a root for a side branch (find the revision which matches a
specified cvs manifest, git id, svn revision number)

The first two functionalities would also enable advanced scripting
functionalities within monotone (already requested IIRC).

PS: this all dawned to me while I noticed that only a small subset of
cvssync had to be changed to support rosters (done).
   Christof

*) cvssync can not change files in an already commited monotone revision
when it pushes it into the cvs repository, so it has to certify a change
in the synchronization information (basically a file/revision map)

Attachment: signature.asc
Description: OpenPGP digital signature


reply via email to

[Prev in Thread] Current Thread [Next in Thread]