Re: [Monotone-devel] cvs_import rewrite

[Markus Schiltknecht]

On Thu, 2005-12-15 at 15:53 -0800, Nathaniel Smith wrote:
> The goal of the last cvs_import rewrite was basically, "use cvs2svn's
> algorithm to get things right" :-).  The main limitations I'm aware of
> with current cvs_import are:
>   -- it doesn't do any branch reconstruction.  This would be _really_
>      helpful; at the moment, this makes its branch handling almost
>      completely useless, because in monotone going forward you won't
>      be able to usefully merge between branches that aren't linked up.
>      The difficulty is that this is necessarily a heuristic operation,
>      and there are states a CVS repo can be in that are simply not
>      possible to meaningfully translate.
>   -- no incremental re-importing.

In that case, I don't really understand how monotone's cvs_import works.
After reading rcs_import.cc I got the impression, that the treewalker
first collects all files and parses them. Then somehow revisions and
branches are created (import_cvs_branch() or what function was that?).

I found it very hard to read the code and I still don't really
understand what's going on. Could somebody quickly outline the algorithm
used and the differences to cvs2svn?

> Right now we just do things in memory, and it seems to go okay.  We'd
> have to look at the argument for how saving stuff somewhere persistent
> would be a significant win, I guess.

I was thinking about helping re-import. A re-import could use
information like what rcs-version of a file is in which monotone
revision - or so. Still a vague idea...

> Intriguing idea!  How do you work out what the merge looks like?

..the next non-overlapping cvs revision would be the merged revision in
monotone, I guess. Even if that wasn't really the case, it's not any
worse than the fixed up CVS repository.

Maybe we could add hooks or have an interactive cvs_import variant where
you could define where (in CVS) the merge really happened? Or more
generally: give the user the possibility to edit the CVS <-> monotone
revision mapping (at least in case of CVS inconsistencies).

> > My goals with this are:
> >  * gain speed in subsequent imports
> 
> Do you have profiling data showing where the bottlenecks are?

Sorry, no. But only having to parse changed files in CVSROOT and only
importing new revisions seems like a sure gain to me. And that could be
possible when storing results from cvs_import.

> (Right now I'm pretty sure the bottleneck is the changeset sanity
> checking, just like for initial pull.  Re-imports don't have to deal
> with that; maybe if we added re-import support it would already be
> plenty fast.)

That's what I meant with 'subsequent imports'

> >  * (correct) branch support
> 
> This would be _really_ good to have, and even an urgent need, as
> mentioned above.  It might even be the first thing you should look
> at/try, as a way of familiarizing yourself with the issues involved in
> CVS importing...

Yes, I'll try. But so far I didn't understand the cvs_import.cc code
enough to find similarities in the algorithm to cvs2svn :-(

Anyway, thanks for your help. I'll read the code again...

Regards

        Markus