Fwd: Bookmarks with hg update question

[Andrew Fischer]

Actually responding to the list this time:

James,

We use a similar workflow to the one you outlined in your message. And I
have run into the same problem you describe below:


> The Problem / Question:
>
> Let's say a developer does the following:
>
> hg up current
>
> (does some other stuff)
>
> hg up
>
> What happens is, the bookmark travels to "tip".
>
> I'm not sure this is right, or expected behavior, but perhaps we are
doing something wrong?


This is expected behavior. The documentation for 'hg update' states:

 " hg update - Update the repository's working directory to the specified
changeset. If no changeset is specified, update to the tip of the current
named branch and move the active bookmark (see 'hg help bookmarks')."

So a bare 'hg update' will end up moving your active bookmark to the tip.


> <snip>
>
> Anyway, to summarize:
>
> 1. Is there a setting or something else that already exists that will
prevent this behavior when doing hg up from a bookmark?
> 2. If not, is this a known problem / is this a problem at all?
> 3. Are we just abusing bookmarks in a way they weren't intended to be
used?
>

Our solution is to simply "never allow a bare 'hg update' command to be
called". As long as the user has to specify a revision argument to 'hg
update' it won't move your bookmark unexpectedly.

So you always have to "hg update mybookmark" or "hg update current" or "hg
update tip" (if it's the tip you really want). That has effectively stopped
any issues for us.

Now since everyone works on the command line here that rule is pretty easy
to enforce using a .bashrc setting that blocks 'hg update' without an
argument. I see that you mention using tortoiseHg and so I'm afraid I don't
know how that would be done with tortoise.

Hope this is of some help at least,
-Andrew


-- 
Andrew Fischer, PhD
Apastron, Co
903 1st ST N Hopkins, MN
952-373-1024
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mercurial-scm.org/pipermail/mercurial/attachments/20160614/dbe97f0f/attachment-0002.html>