how to revert update operation

[Aaron Bentley]

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

Robert Collins wrote:
> On Wed, 2006-07-19 at 23:12 -0400, Aaron Bentley wrote:
>>>They
>>>certainly do -not- mean 'discard my work'. So we have to preserve the
>>>work.
>>
>>They *may* mean 'discard my work'.  This is why I say user intent is
>>unclear.
> 
> 
> No. I fundamentally disagree. The *statement* of running update is
> 'preserve my work'. You can certainly design other commands, but the
> will not be analagous to 'update' in CVS or SVN.

The problem is we are making different statements about what 'my work'
is.  You are stating that 'my work' unambiguously includes branch-local
changes which aren't in the working tree.  If the object is a
heavyweight checkout and the working tree and its branch have different
bases, we are in a very weird state.  Possible ways we got here:

1. The user has two working trees for the bound branch, and they
committed in the other one.  This was deliberate.  Okay, but why aren't
they updating in the branch where they committed?  It seems more likely
that they are trying to get local-branch changes into their working
tree, NOT master-branch changes.

2. The user has two working trees for the bound branch, and they
committed in the other one.  This was a mistake-- the local branch
changes aren't considered part of 'my work for this tree', only for the
other tree.  This situation needs to be resolved by creating a branch.

3. The user has pushed into their checkout over sftp.  In this case,
they may just want to apply the local-branch changes, not the
master-branch changes.

4. Someone else committed into the branch.  Therefore the branch changes
are not 'my work for this tree'.

5. The user has run uncommit --local or update -r to get rid of some
local-branch changes.  Therefore, the branch changes are not 'my work
for this tree'.

I don't see 1. as a particularly sane use case.  I don't know what to
think about 3.

In the rest of these examples, 'my work for this tree' does not include
local-branch changes that are not in the WorkingTree.  Therefore I say:
ambiguity, punt to the user.

>>In my experience, this is nothing like CVS.  CVS/SVN do a three-way
>>update, not a four-way one.  This may be your extrapolation of CVS/SVN
>>to this situation, but that's not the same thing.  CVS never provided a
>>way to check a branch out into another branch, only into a checkout.
> 
> 
> The fact its done as a 3-way merge is interesting but not the key point.
> They could do a knit merge just as well.

Arch's update did not do the same thing as star-merge, and that made it
useful for maintaining diverged branches, because each could apply the
other's recent changes without applying the changes that they disagreed
about.  So I'm not certain that 'update' is equivalent to 'merge' in
that sense.

> They have two trees - the
> shared branch tip, and the current content. We have three, when you have
> a bound branch, and yes, this is my extrapolation, which is AFAICT
> completely consistent with CVS and SVN.

It's not.  When you work with CVS and SVN, you can see all of the
changes that are about to be merged by examining your source tree.  With
the current update command, there isn't even a way to apply the
local-branch changes without applying the master changes.

>>But then, how do I get changes from the master?  That's all update does
>>99.9% of the time, and it's all I'm expecting update to do.
> 
> 
> There are two basic use cases:
>  *) Make my checkout be the same as the latest in master. To achieve
> this 'bzr update, bzr revert'.
>  *) Get the latest stuff from master to be my basis, and my local work
> preserved, ready to commit. To achieve this 'bzr update'

But, I don't want to get local-branch changes, just master changes.
There should never be any local-branch changes; if there are, something
is wrong, and I want bzr to tell me.

>>Yeah, but checkouts look very similar to standalone working trees.  I am
>>saying a mistake like this is possible.
> 
> 
> This is true. Its also, IMO, a reason we have the differences shown in
> 'info', and also have 'bzr branch' which will always make a new branch.

Info is nice, but it's not obvious in the way that status is.

>>It is not what a Darcs user would expect cp to do.  Both types of users
>>exist.  Hence the possibility for mistakes.
> 
> 
> Darcs does not have checkouts, nor AFAIK update. The update and checkout
> commands are specifically for the workflow CVS and SVN users are
> accustomed to, so ...

So Darcs users are forbidden to try out update and checkout?

>>True, but that case is much easier to detect.
> 
> 
> How? By status? Status would have shown you in your example as well.

No, status won't show local-branch changes.

> In that sense, yes it is. However, Alexander had work lost because he
> ran 'revert' after 'update', which is the workflow one users to discard
> ones work!

But it's an easy mistake to make, because 'update' is used in similar
situations to merge, and it's not uncommon to run 'revert' after 'merge'.

>>Using a shared branch is fine, but it doesn't naturally result in
>>situations where the checkout is out-sync-with the branch AND the branch
>>is out of sync with the master branch.
> 
> 
> It *can*, but its somewhat pathological for sure.

Naturally?  I don't see it happening naturally.  You have do do
something weird like making a lightweight checkout of a heavyweight
checkout, or pushing into a heavyweight checkout or unbinding, running
update -r, etc...

> Anyhow, I like the
> idea of making update more robust, so lets focus on that - your stop and
> have them retry on conflicts is good. So we should open a bug for that.

I don't think it's good.  I think it's less bad than what we're doing.

'update' is destructive, so we must be careful to follow user intent.
This is a corner case in which user intent is ambiguous.  So we should
ask the user to explain what they meant, rather than applying changes
they may not wish to apply.

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

iD8DBQFEv4S/0F+nu1YWqI0RAoryAJ4wXT6XHCquA7xbHNTNBzxP2RPKjACeOQnH
I9aLt0cdBcNfZiGbo5889Mc=
=kKO1
-----END PGP SIGNATURE-----