Why Does Update with No Args Move Bookmark?

[Stephen Lee]

On Fri, Oct 11, 2013 at 7:28 AM, Martin Geisler <martin at geisler.net> wrote:
> Stephen Lee <sphen.lee at gmail.com> writes:
>
>> On Thu, Oct 10, 2013 at 12:00 PM, Jensen, Aaron <ajensen at webmd.net> wrote:
>>>
>>> Why does `hg update` without arguments move a bookmark [1]? It seems
>>> like this could cause unintentional problems if someone does work on
>>> a bookmark, and un-mindfully runs `hg up`. This feels like a bug.
>>
>> The short answer is that it simplifies the common scenario where you
>> pull changes from some public server, and you have not made any
>> commits of your own. "hg up" moves you to the tip of the current
>> branch and drags the bookmark with it so you are ready to start
>> working.
>
> That scenario is actually not common in my experience.

Not common then, but certainly possible.
Does anybody out there remember any other reason why update does this?

>
>> If you had made your own commits then "hg up" complains that the
>> update will cross a branch and fails (suggesting you merge). This is
>> the fail-safe that prevents you from accidentally moving the bookmark
>> when you didn't want to.
>
> I've found that this didn't work very well in practice. We tried to use
> bookmarks for a couple of weeks and abandoned them again.
>
> We agreed to let the '@' bookmark show the last reviewed commit on
> default, with the idea that we would advance '@' when a reviewed branch
> was merged into default.
>
> Despite our best efforts, we found that '@' got out of sync on a daily
> basis, e.g., people forgot to update it when pushing to the main server
> or it got updated by mistake.

We have been using bookmarks for a few months now and have had some
mistakes, but only a handful of times.
Are you using bookmarks other than @? We are using bookmarks for
feature branches which means developers usually update to those and
rarely update to @.
Only the integrator updates to @ when merging a branch.

>
> We've now mostly dropped the idea of using bookmarks for anything but
> local markers (but even there I find it easier to just look at the graph
> in TortoiseHg and update to the head I want).
>
> A particularly annoying feature of bookmarks is that they spread like
> crazy and that they display themselves prominently in various lists
> (such as 'hg bookmarks', dropdowns at Bitbucket, etc). It's backward
> that this should be a mis-feature, but that's how it felt to me and my
> team when we suddenly had 30+ bookmarks in our repos.
>
> It's not that we worked on 30+ features simultaniously (we're just six)
> but the problem is that deleting bookmarks is hard by design: even when
> I delete the bookmark locally and on the server, it doesn't help the
> rest of the team if they've already pulled it.

This is becoming a problem for us...
Kevin and I discussed an idea of mine for globally deleting bookmarks.
There were some issues regarding reusing bookmark names (ie. you couldn't).

>
> Git helps here by not showing all branches all the time. If I push a
> branch to the central server, the rest of the team will get it when they
> pull, but the branch lives in the origin/ namespace. It is only branches
> that I've checked out explicitly that I see when I run 'git branch'. So
> tons of branches can come and go in the main repository without
> bothering me.
>
> I've only played a little with Git, but a similar mechanism might be key
> to make bookmarks more managable in Mercurial.
>

I used Git in another project for about 2 years.  The namespacing of
branch names always confused me.
Especially the complex way automatic merge targets were selected when pulling.
The namespacing also caused problems if you created a local clone -
origin would be pointing to your original clone, not the server...
I would not like to see this complexity in Mercurial.

Steve