Re: [Monotone-devel] tweaking ancestry after cvs_import

[Tony Tung]

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.

Thanks again,
Tony