Re: [Monotone-devel] cvs_import rewrite

[Christof Petig]

Markus Schiltknecht schrieb:
>>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...

Perhaps re-import is not needed once cvs_import can store the
information needed for cvssync. Cvssync is efficient when it comes to
synchronize two repositories (small number of revisions, recent changes).

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

That's exactly what cvssync does. Storing this information in an
efficient way is difficult. But since cvs_import creates the revision
(or more specifically the manifest) it can add a hidden file
(.cvsrevisions) which is delta encoded as usual and efficiently stored.

... It occured to me that cvs_pull (cvssync's import) could work that
way ... This would make the storage more efficient and robust. But it
creates a notable difference between cvs_pull (which can change/add
files) and cvs_push (which can only change certificates).

Great idea, I will follow this way and change cvssync (will take some
time to finish)

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

[with CVS manifest I mean a map<file,rcs revision> at a specific changeset]

Of course I thought about branch rooting, too. My current plan is to
calculate the base cvs manifest before the first branch commit (by
removing .N.1 where appropriate IIRC) and look for a monotone revision
matching this CVS manifest (which is easier if the CVS manifest is
stored as a file, so you can look up the revision which contains this
file). Take this monotone revision as the parent of the first revision
to create on this subbranch. If you don't find a matching revision (e.g.
because someone hand-edited the repository or did strange branching
magic) simply let the branch float (no parent revision).

Problems arise from the fact that branch tags are moveable (so you might
not/no longer be able to calculate a name for the branch).

   Christof

signature.asc
Description: OpenPGP digital signature