[Monotone-devel] Re: cvs_import failure

[Hendrik Boom]

On Sat, 02 Jan 2010 11:34:15 +0100, Markus Wanner wrote:

> 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.

Well, it's possible the topological analysis of the CVS repository could 
generate a different graph if a few entries have been added.  Especially 
if it uses time stamps to determine which changes go together.  The graph-
theoretic analysis seems chaotic to me (in the sense that small changes 
could have large effects).

> 
>> 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.

Those are the data you need, yes.  It's conceivable you could deriv some 
of this by recomputing the hash-codes for every file and comparing with 
those of the monotone repository, but that could be time-consuming.  Not 
what you want to do over a network link to a CVS repository.  Probably OK 
for a local one.  I wonder how cvsup does it.

> 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)

Is that what the vanishing attributes were for?

> we want to put an
> additional cert on the revision that really originates from CVS.

Are these certs somehow more space-efficient than storing the CVS 
versions in the certs?
 
> 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.

We seem to have several attempts to implement cvs interaction.  There's 
cvs_import-branch-reconstruction, and there's cvssync.  And there's a 
suggestion to start anew by modifying cvs2svn,  Are these related in any 
way?  Are they on separate branches?  Do any of them somewhat work?

My mental image right now is of modifying some kind of a cross between 
cvsup and cvs2svn to use monotone's automate interface to interact with 
the cert and attribute infrastructure ... but I fear mthat Modula 3 and 
python may argue on a fundamental level.  It might be a better 
algorithmic model than an implementation plan.

Thanks

hendrik