Bookmarks with hg update question

[James Reynolds]

A little background first:

We maintain three active branches as a part of our daily workflow.

Default is our production ready branch.
Release is our QA ready branch.
Development is our dev branch.

Additionally, the Development branch is really a branch of various
bookmarks to facilitate a gitflow like system.

We also, from time to time, have other long running branches that we open
and close for various reasons.

The workflow works like this:

For every ticket created in Jira, we create a bookmark.
For every bookmark, we create a pull request (to default).
Once a ticket has gone through the QA process, we merge (usually in
bitbucket), provided all the reviewers signed off.

This ticket get's assigned to the next tag/fix-version (maintained in jira).
At the end of the day, the release is tied off, a tag is created, and a
deploy is done.

The final step of the is (essentially): hg up current; hg merge default; hg
commit -m "merged default"; hg push -B current;

All bookmarks are cut from a bookmark on the development branch called
"current", as outlined from the process above.

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?

An actual demonstration:

> $ hg up current
> 2 files updated, 0 files merged, 0 files removed, 0 files unresolved
>


> $ hg log -r .
> changeset:   14632:e09b27da1fce
> branch:      development
> bookmark:    current
> parent:      14558:2d729818ba8f
> parent:      14631:ffadb81efb29
> user:        James Reynolds <emails>
> date:        Fri Jun 10 10:26:20 2016 -0400
> summary:     merged default



>
> $ hg up
> 2 files updated, 0 files merged, 0 files removed, 0 files unresolved

updating bookmark current
>


> $ hg log -r .
> changeset:   14654:014abdcbde77
> branch:      development
> bookmark:    bug/SOMEOTHERSCHEME-2145
> bookmark:    current
> parent:      14642:55cae034bfcf
> user:         Another Developer <emails>
> date:        Mon Jun 13 10:08:23 2016 -0400
> summary:     SOMEOTHERSCHEME-2145 fix failing test



$ hg pull -B current
> pulling from ssh://hg@bitbucket.org/a-pretty/awesome-repo
> no changes found
> importing bookmark current
>


$ hg log -r .
> changeset:   14654:014abdcbde77
> branch:      development
> bookmark:    bug/SOMEOTHERSCHEME-2145
> parent:      14642:55cae034bfcf
> user:        Another Developer  <emails>
> date:        Mon Jun 13 10:08:23 2016 -0400
> summary:     SOMEOTHERSCHEME-2145 fix failing test

oh, and lest I forget:

$ hg --version

> Mercurial Distributed SCM (version 3.8.2+6-89bba2beb03e)
> (see https://mercurial-scm.org for more information)
> Copyright (C) 2005-2016 Matt Mackall and others
> This is free software; see the source for copying conditions. There is NO
> warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.


This seems to happen the most with my developers (primarily designers, who
are not as comfortable with the command line) who use GUI tools such as
tortoise the bitbucket product, however it can happen to anyone.

This isn't so bad if it's caught early, but now that current has "moved",
the next time they do hg up current; hg bo bug/ticketnumber; they are now
descended from the wrong place - tying these two tickets together and
causing a lot of confusion amongst the developers.

Asking my developers to always do hg log -r . seems like an unnecessary
burden for topic branch management.

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?

Ultimately, it's important for me and my team to maintain a topic branch
system - this is the best way that we've found to collaborate across
tickets, maintain rapid deploys, and generally keep the velocity at a high
pace.

I'd rather not have to fight with my VCS system for my team to productive.

Any incite any of you can provide would be of great value to me.

James Reynolds
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.mercurial-scm.org/pipermail/mercurial/attachments/20160614/6c950f12/attachment.html>