Bookmarks with hg update question

[James Reynolds]

On Wed, Jun 29, 2016 at 5:00 AM, David Demelier <demelier.david at gmail.com>
wrote:

> Le 28/06/2016 19:05, Becker, Mischa J a écrit :
>
>> From: Scott Palmer
>>> Subject: Re: Bookmarks with hg update question
>>>
>>> Am I the only one that thinks the current behaviour makes sense?
>>>
>>> Scott
>>>
>> If I recall correctly, bookmarks originally mimicked git branches.
>> Anyone coming to hg from git intrinsically understood bookmark behavior.
>> Those of us who came to hg from reading books found bookmark behavior
>> weird. :)
>>
>> I'm slightly surprised there haven't been several other people pushing
>> for bookmarks to stay exactly as is.  Maybe there are less git to hg people
>> currently following the list.
>>
>> Mischa
>>
>
> We all understand how bookmarks work.
>
> We (some, including me) just think that 'hg up' with no arguments should
> not move bookmarks because it's too easy to move bookmarks by mistake
> because:
>
>   1. All tutorials show to use 'hg update' when pulling changes,
>   2. Even the command 'hg pull' will give you a hint to use 'hg update'
> with no arguments.
>
> Why I think it's a real problem:
>
> A user (not a developer), not very familiar with Mercurial is watching  a
> repository that have the @ bookmark. The developers make some commits, @
> moves and the simple user pull and update. No problem so far.
>
> Now the team decides to work on something a bit experimental, they
> deactivate the @ bookmark and use something else like 'big-change-break'.
> They start adding new changesets, of course in the official repository the
> @ bookmark does not move anymore, problem, the user is still doing 'hg pull
> && hg up' or eventually 'hg pull -u'. Yikes, the user has just moved the @
> bookmark to the tip (where 'big-change-break' actually points) and may use
> something completely WIP / unstable.
>
> What I would like to see eventually:
>
> If hg update is called without argument and the current activated bookmark
> is not in the same revision than the pulled one *and* they are in the same
> head, we can move to that new changeset.
>
> Example (assuming user has @ activated, {} means working copy, () means a
> bookmark, * means activated):
>
>   1. Before, in the user local repository: A -> B -> {C} (@*)
>   2. After 'hg pull': A -> B -> {C} -> D -> E (@*) -> F -> G
> (big-change-break)
>   3. After 'hg up': A -> B -> C -> D -> {E} (@*) -> F -> G
> (big-change-break)
>
> Regards,
>
> --
> David Demelier
>
>
> _______________________________________________
> Mercurial mailing list
> Mercurial at mercurial-scm.org
> https://www.mercurial-scm.org/mailman/listinfo/mercurial
>




A lot this discussion in interesting, and I think this large amount of
discussion should demonstrate that bookmarks are confusing. If they
weren't, there wouldn't be much discussion.

I'm personally still in favor of my initial proposal from earlier, which
allows teams to opt into a usecase of bookmark that simply doesn't
magically move a bookmark on a blind hg up. For those who want the legacy
behavior, they can just leave everything alone.

Ultimately, what really needs to happen, is a real examination of using
bookmarks in a large distributed team environment focused on "topic branch"
development.

If other's are also in favor of what I wrote earlier, I'll try to see if I
can't get it submitted and accepted.

The advantages I see are:

a.) doesn't break workflow for anyone.
b.) don't have to wait around for he next major release
c.) doesn't break backwards compatibility.
d.) Those who want a workflow that isn't insane, can have it with relative
ease.

Disadvantages:

a.) requires coordination across a team to coordinate settings.
b.) will still confuse the heck out of new uses since it's not likely they
will know about the setting.

James Reynolds
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mercurial-scm.org/pipermail/mercurial/attachments/20160629/cb78db36/attachment-0002.html>