monotone-devel
[Top][All Lists]
Advanced

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

[Monotone-devel] Re: state of cvssync


From: Christof Petig
Subject: [Monotone-devel] Re: state of cvssync
Date: Wed, 04 Oct 2006 23:19:38 +0200
User-agent: Thunderbird 1.5.0.7 (X11/20060918)

Graydon Hoare schrieb:
> I was wondering if you could point me to (or provide) a brief
> description of the work you've been doing on cvssync recently, what it
> does, and what its status is. Interoperating with other VC tools is one
> of the things I'd like to get a handle on eventually.
> 
> I've always been hopeful for something /like/ what you initially
> proposed and implemented, I've just found myself not understanding what
> the code does or how it does it, so skeptical about directly merging the
> code.
> 
> If I understand correctly you're moving some or all of the logic into an
> external tool now, and interfacing with mtn via automate?

Just before I leave for a week long journey to Turkey ...

I completely separated the cvs server interaction logic from monotone
and created a new binary mtn_cvs which opens a pipe to (ssh+)cvs and
monotone automate and synchronizes in one direction (real bidirectional
sync is not useful because cvs does not support nonlinear histories).

To accomplish this I created some new monotone automate commands (get
and set database variables which I happen not to need ;-), committing
files and revisions without an intermediate working directory, and
finding the last synchronized revision and it's synch state.

Mtn_cvs uses a good part of monotone's infrastructure (ui, sanity,
option, Netxx::PipeStream, testsuite.lua) but is a perfectly separate
tool in itself.

What is done:
- mtn_cvs pull works with side branches and all sorts of strange setups
(see tests)
- mtn_cvs push does not seem to work, yet (I don't know which commenting
out stands in the way)
- mtn_cvs takeover is not finished since it used the workspace
infrastructure from mtn and is not ported to being standalone yet. [And
I have to implement changed files correctly instead of using dummy
revisions within monotone which is inelegant]

What needs to be done:
- fix push
- port takeover
- implement changed files
- switch to using file and directory attributes instead of a
synchronization file
- implement a sane branch connecting
- share the changeset-ification logic with cvs_import (I use the most
simple approach for now)
- write documentation

What can be put into mainline:
- the piece_table abstraction can be shared with cvs_import (once I had
committed the change)
- all automate extensions (the synchronization commands are about to
change again to use attributes, so they might wait)
- the mtn_cvs directory infrastucture can be put into mainline but can
wait as well until it's finished

    Christof

Attachment: signature.asc
Description: OpenPGP digital signature


reply via email to

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