probably bug? update in lightweight checkout of heavyweight checkout turns local commits into pending merges

[Alexander Belchenko]

John Arbash Meinel пишет:
> Alexander Belchenko wrote:
>> I don't know is it bug or feature, but I think it's the bug. At least
>> this behavior
>> was very undesirable for me.
> 
>> I did heavyweight checkout from server, then I did lightweight checkout
>> from heavyweight checkout.
>> When I did local commit in heavyweight checkout and then update in
>> lightweight one I get
>> pending merges in lightweight checkout (???) and uncommit (!!!) in
>> heavyweight checkout.
> 
>> I think something wrong here. You may think different.
> 
>> Here is sequence of steps to reproduce (I ran this in C:\Temp\1 directory):
> 
> 
> That sounds like expected behavior, though I'm not sure if you wanted
> it. Specifically, you can get the same behavior without the extra checkout.
> 
> bzr checkout upstream checkout
> cd checkout
> bzr commit -m "local only" --local
> bzr up
 >
> You now have pending merges in the heavy checkout because it updated to
> the tip of the master branch.

No I'm talking about lightweight checkout. I can't create local commit in lightweight checkout.

> That is by design, though there have been discussions if it is the
> "correct" design.

I have no objections to heavyweight checkout behavior. I just don't want to get side effect
from lightweight checkout update.

> The only difference in your workflow is that you added a second
> lightweight checkout to the mix. But it doesn't really act any differently.

1) I never saw pending merges in lightweight checkout. And in the case of chain
branch -- lightweight checkout I can't create local commit.
2) Update in lightweight checkout destroyed history in heavyweight checkout.

If you say it's the "correct" behavior, I'd like to understand why you think it's correct.

> I understand that what you probably wanted to say was "update this
> lightweight checkout to the tip of its branch, ignoring that the branch
> is bound to a master."

Yes, that's exactly what I want to do.

> However, "bzr update" is defined as "update this
> branch to the tip of its master (if exist), and update this working tree
> to the tip of the branch afterwards."

I don't understand this definition. Who is "this branch" in my case? And who is "its master"?

> We've talked about a few different ways of doing it, what is your
> specific use case (why are you using a lightweight checkout of a heavy
> checkout, etc.).

I think I could avoid this unpleasant behavior if I do unbind of heavyweight checkout
instead of local commit. I just was lazy. I need local commit because it was not intended
to be commit for server, it just to update lightweight checkout. And I'm trying to avoid
do `merge --uncommitted`. As I said I was lazy and thought that bzr will allow me such trick.