[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Monotone-devel] cvs_import rewrite
From: |
Markus Schiltknecht |
Subject: |
Re: [Monotone-devel] cvs_import rewrite |
Date: |
Fri, 16 Dec 2005 09:10:36 +0100 |
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
[Monotone-devel] Re: cvs_import rewrite, graydon hoare, 2005/12/16