Why Does Update with No Args Move Bookmark?

[Martin Geisler]

Stephen Lee <sphen.lee at gmail.com> writes:

> 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?

I think your reason is the correct one, it's just that I don't feel it
occurs that often.

This is probably also different from team to team. We do web development
and usually work independently on each feature or use pair programming.
We don't really share feature branches before they're ready to be merged
and maybe that's why I don't often need to forward a bookmark in the
automatic way 'hg up' does.

>> 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.

That probably makes a difference: we don't have a designated integrator,
instead we assign one or two reviewers to each feature and one of them
will do the merge back.

>> 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).

Yeah, you can't have your cake and eat it too :)

>> 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.

I don't have the long-term experience with Git, so thanks for mentioning
this. I've heard others mention similar problems and we should of course
try to avoid them. We should learn from them and avoid the bad parts :)

-- 
Martin Geisler
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 835 bytes
Desc: not available
URL: <http://lists.mercurial-scm.org/pipermail/mercurial/attachments/20131011/5a3649b2/attachment.asc>