probably bug? update in lightweight checkout of heavyweight checkout turns local commits into pending merges
Alexander Belchenko
bialix at ukr.net
Mon Mar 17 17:56:02 GMT 2008
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.
More information about the bazaar
mailing list