tree-less merges

[Michael Hudson]

Replying to two mails at once here...

Aaron Bentley wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Michael Hudson wrote:
>> I have a need (for a submission script/pending reviews page; I guess
>> send/bundle buggy could conceivably use something like this)
>
> For send, it makes more sense to show what changes were performed,
> because we don't know what the merge directive will ultimately be merged
> into.

Oh right, that makes sense.

> But for Bundle Buggy, there might be a place for it.
>
>> I talked to John and Robert a bit about this in #bzr.  John suggested
>> creating a LazyWorkingTree type (which had been my first thought too),
>> but Robert (and Aaron overnight) suggested that subclassing Merger or
>> TreeTransform might work better instead.  This makes sense to me, but
>> both transform.py and merge.py make my head hurt[1], so I'd really
>> appreciate a few hints as to where to start with this.
>
> I'm always interested in ideas to make the interface clearer.  TT in
> particular does not come off as friendly.

I think TT would be helped by a little more documentation about what
all of the _new_id, _r_new_id, _new_contents, ... mappings are all
about, and also short explanations of what concepts like 'transaction
id', 'limbo', etc are.

Once you've got past that, I think the confusion mostly comes from the
fact that a TT instance has a lot of state, and it's not always
immediately clear which bits of it are affected by a particular method
call.  I don't see how this can be helped, though, it's pretty
inevitable that a TT has a lot of state.  I'm getting there, I think.

> AIUI, you really care about conflicts, but I'm not clear whether you
> care about all conflicts, or just text conflicts.

I think I care about all conflicts, but it has to be said that in
Launchpad's pending branches page (which is more or less my motivating
example here) text conflicts are massively overwhelmingly the
commonest type of conflict.

> If it's just text conflicts, you can probably get away with subclassing
> Merge3Merger.  If you want to predict content conflicts, naming
> conflicts, etc, you'd have to subclass (or otherwise refactor) TT.

Well, you later prodded me in the latter direction anyway...

>> It looks a bit to me that it will probably require changes to core
>> bzr, afaict.
>
> Well, if you subclass TT, you'll need a way to force Merge3Merge to use
> your subclass.

Hm, yes, though that doesn't qualify as very deep hacking :)

>> [1] For something very simple, the fact that there's no subclass
>>    relationship between Merger and Merge3Merger is pretty confusing.
>>    Should one of them be renamed?  Merger could become MergeDirector,
>>    perhaps?
>
> Yes, that might be an improvement.

I'll try to remember to submit a bundle that does that...

Aaron Bentley wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Michael Hudson wrote:
>> I talked to John and Robert a bit about this in #bzr.  John suggested
>> creating a LazyWorkingTree type (which had been my first thought too),
>> but Robert (and Aaron overnight) suggested that subclassing Merger or
>> TreeTransform might work better instead.  This makes sense to me, but
>> both transform.py and merge.py make my head hurt[1], so I'd really
>> appreciate a few hints as to where to start with this.
>
> Here's the sort of thing I was talking about.  The idea is to implement
> a variant of Transform that lets you get a PreviewTree.  The PreviewTree
> should implement enough of the Tree interface that you can run
> show_diff_trees against it, but that's all.
>
> Then you run merge using this special TransformPreview, get the preview
> tree, and run your diff.

Thanks a lot!

Here's a diff (not a bundle as I merged in both your
transform-preview.patch and differ.patch bundles first and it wasn't
then instantly obvious how to generate a bundle against this) that
makes a lightly extended test_diff_preview_tree pass.  If you could
look it over and tell me whether it appears sane, I can probably make
good progress from here by myself.

Cheers & thanks again,
mwh