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
_______________________________________________ Monotone-devel mailing list [email protected] http://lists.nongnu.org/mailman/listinfo/monotone-devel
