Re: [Monotone-devel] Re: cvs_import failure

[Markus Wanner]

Hello Hendrik,

Hendrik Boom wrote:
> The question here is whether the proposed cvs2mtn, on repeated use, would 
> produce monotone repositories that could be synced.  I suspect not.

As long as you only *add* commits to the source CVS repository, that
should not be much of an issue. Do a new conversion to monotone and sync
with the existing monotone repository.

> There's free software, cvsup, that maintains a local copy of a remote CVS 
> repository.  It might have some ideas that could contribute to a 
> continuous update, but I don't know how it deals with manual mangling 
> either.

Lots of places use rsync instead of cvsup nowadays. However, I don't
think that has much to do with continuous updates. The issues for that
feature are:

 * being able to determine what RCS versions the single files of the
head in monotone (i.e. the last imported version) are. Then continue to
import from there, if there are any new commits.

 * figuring out, if there are changes in CVS to revisions that have
already been imported.

> I suspect that getting any conversion is more important than getting an 
> ongoing continual update working.  But it's possible thinking about the 
> problem will generate some ideas.  I'll keep it in mind when I start 
> reading existing code.

I've already discussed this topic with Christoph Petig, author of
cvssync (check the refactored branch for most up to date code). We
figured it's necessary to track the RCS version for each file included
in a revision to be able to determine a point to continue from.

That's quite a bit of meta-data, which rarely changes. Storing that
information as part of a certificate would get you a lot of certificate
data, which is not delta compressed. Instead I've proposed to implement
"vanishing attributes", however, the use case for those is pretty limited.

So what we came up with (at the Mountain View summit, IIRC) is a
combination: store the origin RCS versions as attributes, these are
delta compressed and don't take up much space if they remain unchanged.
To differentiate a descendent revision which doesn't originate from CVS
(but "accidentally" retains the RCS version attribute) we want to put an
additional cert on the revision that really originates from CVS. That
way we use the existing infrastructure (attributes and certs) and don't
need to implement anything, but still profit from delta compression of
that information.

I've implemented the addition of attributes and certs (in
cvs_import-branch-reconstruction), but not the reading back of that
information for contiguous imports. I don't know about the status of
that for cvssync.

Regards

Markus Wanner