Introducing Shelf 2

[Aaron Bentley]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

John Arbash Meinel wrote:
> Aaron Bentley wrote:
>> Should we:
>>  - make bzr depend on patch?
>>  - implement inexact patch ourselves?
>>  - teach shelf to update the hunk positions so we can do exact patching?
>>  - change the UI to not use unified diffs?

> Is there any chance we could save snapshots rather than diffs and then
> we can use the regular 3-way merge logic to re-apply them?

Absolutely.  That's already the case.  Patch is only used at the UI layer.

> The idea would be:
> 
> 1) Compute the diff from the current text to whatever base text
> (--revision if given, otherwise wt.base_tree()).
> 
> 2) Capture the (file_id, revision_id) key that represents the base text.

Actually, I'm storing the base tree's revision_id, but this is implied.

> 3) Allow the user to edit the diff hunks as they see fit.
> 
> 4) Apply that new diff to the base text, and store that.

We diverge here.  I apply the new diff to the base text, and write that
to the working tree's TreeTransform.  Then I use a reverse merge to
apply the opposite change, and store that as the shelved change.

> Alternatively, we can still store the diff as long as we store the base
> text it applies to. Then when we go to apply it, we just extract the
> base text, and apply the diff, and then we have a 3-way merge.
> 
> One of my big complaints with 'bzr shelf' right now, is that if the
> patch won't apply cleanly it would refuse to 'unshelve'. I've run into
> that by shelving and making a change to the same line. I'd rather end up
> with a conflict than not be able to unshelf.

As I explained in the original announcement, Shelf 2 uses merge3 to
apply the changes when unshelving.

> I'd rather not make bzr depend on patch if we can help it.

What you proposed is very close to what I implemented.  But both of them
still require applying patches to the base text, and that is what causes
bzr to depend on patch.

> It sounds like we would still need to teach shelf to update the hunk
> positions, and then also store extra information.

Okay, so you're voting in favour of avoiding the dependency by making
shelf smarter, and using our homegrown patch-application code.

> It may be more work than you think is worthwhile, though I think the
> end-result would be nicer.

I think that this is probably the simplest way of removing the
dependency.  Unless I'm mistaken, it only requires maintaining an offset
and applying that offset to patch hunks.

Aaron
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAkjvzmkACgkQ0F+nu1YWqI3LlgCcD3JZzxkzLaz+4QqPh2fkztnJ
B54AnisWpqR5Cj1JXzxgf7uL+0IaUH0C
=J9py
-----END PGP SIGNATURE-----