Simple usage pattern seems problematic ?

Haszlakiewicz, Eric EHASZLA at transunion.com
Mon Jan 24 12:10:22 CST 2011


>-----Original Message-----
>From: mercurial-bounces at selenic.com [mailto:mercurial-bounces at selenic.com]
>
>On Sat, Jan 22, 2011 at 11:46 PM, JonnyDee <jonny.dee.1 at googlemail.com>
>wrote:
>> Hi,
>>
>> On Jan 22, 2:09 pm, Isaac Jurado <dipto... at gmail.com> wrote:
>>> On Sat, Jan 22, 2011 at 1:52 PM, Maxim Veksler <ma... at vekslers.org>
>wrote:
>>>
>>> > Developer can't update his local workspace without committing all of
>his
>>> > local changes first. Why this constraint exists?
>>>
>>> That is simply not true.  When you update a "dirty" working copy,
>>> Mercurial merges it with the destination revision (conflict resolution
>>> included).  The only constraint imposed by mercurial is when you do
>>> this crossing named branches.
>>
>> it isn't possible when crossing branches in general. If you try to
>> update from one topological head to another one within the same named
>> branch it won't work, too.
>
>Ouch!  You are right.  I was writing thinking in the "fast-forward"
>merge.  Sorry for the confusion :-S

You can work around this limitation/bug by doing an update backwards to the branch point, then forwards to the branch you want.

A---B
 \--C
i.e. if you're sitting at rev C and you want to switch to rev B:
  hg up -r A
  hg up -r B

I highly recommend staying away from the --clean option to "hg update".  It's a great way to lose your changes.

You still can't do a merge with local changes though.  For that, assuming you're willing to wait for the time it takes to make another clone, one way to do it is to clone your working directory, do the merge in the new clone directory, then push back to the original clone, and finally update in the original clone.

eric



More information about the Mercurial mailing list