VersionedFile.walk deprecated?

[Martin Pool]

On 11/04/2006, at 3:26 PM, Aaron Bentley wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Martin Pool wrote:
> | On 11/04/2006, at 1:43 PM, Aaron Bentley wrote:
> |> So, it sounds to me like both knit and weave can support   
> plan_merge, but
> |> weave will implement it one way, and knit another.  If so,   
> VersionedFile
> |> shouldn't implement plan_merge(WeaveFile should), and my patch that
> |> moves it into PlanWeaveMerge is also wrong.
> |
> | Well, it could be abstract (and currently inunimplemented) in
> | VersionedFile.

> Right.

Just to expand on what I said before - the problem with walk() is  
that it returns all lines in the history of the file, even those  
which are irrelevant to the two versions we're trying to merge.   
Touching them is not just specific to weave storage, but an  
undesirable consequence, since we spend time walking lines we can't  
possibly use.

We can make a plan_merge for knits which does something similar, but  
only deals with lines which can possibly be in the output.  It  
requires annotated knits.  It should work like this:

   Do a two-way diff between the two versions to be merged.  Within  
the difference regions, we need to determine whether each line is  
unborn, live, or killed in the other side.  Taking the lines from the  
left-hand-side conflict region first, get the line origins.  If that  
origin is in the merged-revisions set of the right hand side, then  
the line has been deleted (or moved) on the right hand side.   
Otherwise, it's new on the left hand side.

This can still be improved for some criss-cross merge cases by  
recording when the user explicitly choses a resolution to a conflict,  
but I think this may give comparable results to current weave merge.

-- 
Martin