how to revert update operation

[Aaron Bentley]

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

John Arbash Meinel wrote:
> Well the premise that I believe Robert was following when he wrote it,
> was that if you are a checkout, you are declaring that the other branch
> is the 'master', and you really want to follow it. (After all, you could
> always just unbind if you wanted to go another way).
> 
> So 'bzr update' actually updates you to the 'master' branch revision,
> and then merges your old working tree into it, and sets the pending merges.
> 
> I *think* we forbid update if there are local commits, and some
> uncommitted changes. If it doesn't, it probably should.

No, the code is specifically intended to handle that: "pathologically
[wt.basis_tree(), wt.branch.basis_tree() and
branch.get_master_branch().basis_tree()] may all be different, and
non-ancestors of each other." and "we want to preserve the
wt.basis->wt.state"

wt.branch.basis_tree() can only be a non-ancestor of
wt.branch.get_master().basis_tree() if there are local commits.

It should be illegal for wt.basis_tree() to be a non-ancestor of
wt.branch.basis_tree(), so that part of the comment seems spurious.
Similarly, wt.basis_tree() is an ancestor of wt.

> Is there an easy way with the merge and TreeTransform code to say "take
> this tree, merge it into this other tree, and then replace the original
> tree with the merged result"?

I'm not clear how that's different from a normal merge.

> I think the code is doing 'merge this into other' which creates a state,
> and then does 'merge state into this' to update the working tree.

Doing two merges in succession seems bogus to me, because the first
merge may produce conflicts, and one cannot do a second merge until
those conflicts are resolved.

Furthermore, it's not at all clear to me that the user wants the
branch.last_revision() to be merged with the master.  If they have a
bound branch, and their working tree is out of date with the branch,
this suggests that someone else has committed or pushed into the branch.
 They may not be aware of these new revisions, and they certainly
wouldn't have reviewed them, since they're not the current tree state.

So, I think if the master branch is defined, and the wt.last_revision()
!= branch.last_revision(), you're in an error condition.  We should
explain the situation to the user, and get them to run either update
- --checkout, (update checkout to the last revision in the branch), or
update --branch (update the checkout to the last revision in the master
branch).  Update --branch would have the additional effect of
uncommitting those revisions which are present in the branch, but not
the checkout.

> The difficulty is that you don't want to just merge other into this (you
> have bzr merge for that). You want to replace this with that, and merge
> the original this.

The direction of the conflict markers and last_revision vs
pending_merges are the only differences I can see.

The merge code does assume that THIS is the output directory.  I am not
sure that you'd really want to swap THIS and OTHER in the conflict
markers.  If you did, it would be best to do it as a parameter to the
text mergers.

Swapping last_revision and pending_merges should be easy.

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

iD8DBQFEvQmo0F+nu1YWqI0RAg51AJ9F1eJJVH93eiKdbNE/eAz1d21sQACcCo9H
9P5+yCYVJwlw9WgNNzR/JCU=
=eC2o
-----END PGP SIGNATURE-----