how to revert update operation

[Robert Collins]

On Tue, 2006-07-18 at 12:17 -0400, Aaron Bentley wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
...
> 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.

Not at all. Take a branch, make two lightweight checkouts, commit in on,
update in the other, uncommit while you are there, then do a new commit.
Now go to the other light checkout, and the tree's basis_tree is not an
ancestory of the branch's basis_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.

For shared branches, the 'review before I accept it' workflow is not
present. If users want to do that they should not be using a shared
branch.

> 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.

Well, we could do that, but I think its just exposing machinery to the
user for no good reason. Perhaps I'm missing something?

> > 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.

Its possible that the conflict markers can be improved for update - but
at the moment its actually correct AFAICT - 'THIS' is the tree the user
starts with, 'OTHER' is the code coming in from the shared branch.

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: 191 bytes
Desc: This is a digitally signed message part
Url : https://lists.ubuntu.com/archives/bazaar/attachments/20060719/52c36198/attachment.pgp