[MERGE] Implement Tree.plan_merge, deprecate RevisionTree.get_weave

[Robert Collins]

On Thu, 2007-07-19 at 10:22 -0400, Aaron Bentley wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> Robert Collins wrote:
> > On Thu, 2007-07-19 at 08:40 -0400, Aaron Bentley wrote:
> >> Robert Collins wrote:
> >>> It seems prone to losing a
> >>> users data e.g. during a power-off or kill -9 situation as well as
> >>> requiring more work at the tree layer to discard and recreate the cached
> >>> parent data.
> >> Yeah, the question is whether we care enough in these situations:
> >>
> >> 1. remerge is rarely used
> >> 2. user files will also be a mess in this situation, so it's only
> >>    incrementaly worse
> >> 3. if we do lose the parent data, users can just do "revert" and "merge"
> >>    instead.
> > 
> > I think it would be very surpising to a user, as they won't have any
> > reason to think this could have happened - they may happily finish their
> > merge and commit, but without the parent data - introducing conflicts.
> 
> Really?  They would hard-kill a remerge and then commit?  With all their
> files out of whack, I really think the parent flag is the least of their
> concerns.  They will still get bad results no matter what if they commit
> after a killed remerge.  Files may be missing.

Thats not quite what I meant, rather that something would happen and
they'd come back after a power glitch or some such and not know. If its
going to be blindlingly obvious then I'm ok with this; though the
performance implications are still uncomfortable.

All the same I've seen your monkey patch and thank you for playing with
it. I wonder if it will make wt4 cry on the inside if merge calls
_write_inventory? So - and I hate to be making you churn your code -
what you had originally is probably safer on balance; however the extra
comment you put explaining it is really helpful; please keep that.

+1

> > On consideration I'd really rather see this controlled through a flag to
> > the function or something.
> 
> What bugs me about this is that it really is accurate information-- if
> you remerge, you set the file contents to their old values.  And so the
> the old parent flags are the correct parent flags for those contents.

Its a shame we can't do it at a per-file basis.
..
> > well both ancestors and get_revision_graph do full graph traversal, its
> > just that ancestors flattens the graph
> 
> The fact that the graph representation can substitute for a set of
> ancestors is pure happenstance, and not particularly obvious.
> 
> > - personally I don't see using
> > get_ancestors in a loop as being clearer. But its definately much
> > slower.
> 
> Please describe a use case in which it will be slower, then.  The only
> one I can think of is merge --force --weave.

Any time you have two parents. I don't know this part of the code base
well enough to say what will trigger that.

...

> Yes.  For each uncommon line, we need to find out whether it was
> introduced by an uncommon ancestor or a common one, in order to decide
> whether it's new in A or killed in B.  We know that if the line was not
> introduced by an uncommon ancestor, it was introduced by a common one.
> So all we need, actually, is the set of uncommon ancestors.

And we're pretty close to being able to get that trivially; I wonder if
there would be (at this point in time) a performance difference by doing
this for regular 'merge --weave'

-Rob
-- 
GPG key available at: <http://www.robertcollins.net/keys.txt>.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
Url : https://lists.ubuntu.com/archives/bazaar/attachments/20070720/6a2da615/attachment-0001.pgp