Re: [Monotone-devel] Re: cvs_import failure

[Markus Wanner]

Hello Hendrik,

Hendrik Boom wrote:
> Well, it's possible the topological analysis of the CVS repository could 
> generate a different graph if a few entries have been added.

With just using cvs commit to write to the cvs repository, that should
not be possible, no matter how silly your clock skews.

> Especially 
> if it uses time stamps to determine which changes go together.

The cvs2svn approach (and thus nvm.cbr as well) doesn't use timestamps
for that. It uses author and commit log info.

> The graph-
> theoretic analysis seems chaotic to me (in the sense that small changes 
> could have large effects).

Maybe a little explanation helps: a single RCS file consists of versions
numbered 1.1, 1.2, 1.3, ... plus branches like 1.1.2.1. For every commit
to the file, the counter is incremented by one, so there's a pretty
simple and clear dependency: 1.1 must have been committed before 1.2,
that in turn before 1.3 and so on. Similar applies to branches.

Collecting these inter-file dependencies, you get a simple DAG. However,
you get a DAG per RCS file, meaning a lot of DAGs. Where as we need just
exactly one single DAG for monotone.

So, in a next phase, we try to match commits to different files (by
matching author and changelog, *not* timestamps) and collect those into
a so called blob. If you keep the intra-file dependencies, you now have
dependencies between blobs. Unfortunately, the resulting graph may be
anything but acyclic, which is where the fun begins...

If you just add to a CVS repository (by committing via cvs), you just
add new blobs which have dependencies on existing ones, but not the
other way around. Toposorting the graph should yield correct results.

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

nvm.cbr as well as cvs2svn only operate on local copies of complete CVS
repositories.

> I wonder how cvsup does it.

I strongly suspect cvsup uses RCS version numbers - that's what makes it
fast.

> Is that what the vanishing attributes were for?

Well, yes. Not that those exist, though.

> Are these certs somehow more space-efficient than storing the CVS 
> versions in the certs?

Huh?

Such a cert would only say, i.e. "origin: cvs_import". That's a few
bytes per revision. Storing an RCS version per file per revision would
be a lot more. Thus that goes into the attributes, where it's delta
compressed. (Well, should be that way. Not that there's any useful
implementation, but that's the idea).

> We seem to have several attempts to implement cvs interaction.

Well, yeah, it's an open source project ;-)

> There's 
> cvs_import-branch-reconstruction, and there's cvssync.

cvssync focuses on contiguous synchronization (also from monotone back
to CVS), however, it doesn't handle branches or silly repository data.
That's where cvs2svn is good at.

nvm.cbr is (has been?) my attempt to implement the algorithm of cvs2svn
(2.0, that is) as part of monotone.

> Are they on separate branches?

Yes.

> Do any of them somewhat work?

Yes, somewhat. Test with your own target repositories.

Regards

Markus Wanner