Re: [Monotone-devel] tweaking ancestry after cvs_import

[Christof Petig]

Tony Tung schrieb:
> On Aug 4, 2006, at 7:15 PM, Nathaniel Smith wrote:
> 
>> On Fri, Aug 04, 2006 at 05:42:17PM -0700, Tony Tung wrote:
>>> Any thoughts on how to indicate a branch collapse in the database?
>>> As I understand it, the predecessors' hash is part of the computation
>>> of the revision hash.  That would mean that all successor hashes
>>> would need to be updated....
>>
>> Right, there's only one way to indicate "branch collapse" in the
>> database -- just make the successor a monotone-style merge revision.
>> But I don't have any ideas on how to actually do this conveniently for
>> cvs imports.  The information is definitely not in the cvs repo, so we
>> can't work it out automatically during import.  It's not even clear how
>> we could provide an interface to say "hey, cvs_import, when you reach
>> this point stick in a synthetic merge node", because in the cvs
>> representation that cvs_import starts with, there _is_ no way to say
>> "this point", since there are no tree versions.  You could do the
>> whole import "by hand" somehow, or maybe doing a bit with cvssync,
>> then doing a merge by hand, and then adding cvssync metadata by hand
>> so that it can continue onwards...
> 
> I envisioned something like a normal cvs-import, but following that, a
> user could then manually assign ancestors to fix up the tree.
> 
> mtn cvs_import ....
> mtn add_ancestor <parent-revid> <child-revid>
> 
> A less optimal way is to use some kind of a fixed cvs tag naming scheme
> to denote merge points.
> 
>> But honestly your best bet is probably to just shrug and say "well, we
>> got on without that information before, let's just import as
>> losslessly as we can now, and with our new better tool we'll record
>> better data in the future."
> 
> Since the above isn't available, I will most likely go with this
> mentality. :)
> 
> Is there a guide to using the cvssync branch?  I'm having some
> difficulty getting it to compile.

Sorry, I broke it by an unwanted back-propagation of the
cvssync.refactor code. But since the rewritten (but not yet finished)
code has a lot of benefits (speed, correctness) I don't care that much
about the old one. Though squeezing free time out of my calendar has
proven difficult during the last week.

Cvssync has code to correctly connect side branches (and a failover plan
once the branch point isn't part of the main branch [easily possible
within CVS]) but that code was never production ready.

You might try e025e7e5a4826f8a3f117ece343ee99c6306f9c2, but it will not
connect side branches (though (re-)im- and export them).

  Christof

signature.asc
Description: OpenPGP digital signature