Why bare 'hg update' needs behaviour change

[David Demelier]

I know this topic has been discussed many times. I know that Matt
still disagree with me but I still think that this behaviour needs
reconsideration.

Consider the following:

An online repository uses bookmarks to develop some features to avoid
using named branches. There is actually the @ bookmark and one
experimental-feature bookmark that only developers must use to avoid
basic users using it.

The developers have worked on it so it is located in several
changesets ahead of @ and the repository looks like this:

o changeset: 10
| bookmark:  experimental-feature
| summary:   adding z
|
o changeset: 9
| summary:   adding y
|
o changeset: 8
| summary:   adding x
|
o changeset: 7
| bookmark:  @
| summary:   fix typo

As you can see, the changeset 7 is the one that "normal" users should
point to. Only developers that care about experimental-feature must
have a local working directory on changeset 10.

Now assume that one user has a local repository pointing at 7 and has
not fetched any new changesets at the moment.

Problem #1

Countless of documentation recommend to use hg pull; hg update. Even
hg pull will tell you to use 'hg update' with no arguments.

The user fetch the changesets and then call 'hg update'. Oops, the
repository is now pointing at revision 10 while it was using the
active @ bookmark. The user will probably have a non-working software.

Problem #2

A normal developer that does not care about the experimental-feature
has done the same thing. It adds some code, commits and push. Oops,
now its revision is mixed between the experimental-feature and the
"default" line of work.

Named branches behaviour

When using named branches, calling hg update with no arguments will
update the local working directory repository to its tip unless there
are several heads where hg complains and asks for a specific revision.
Correct and expected.

Bookmarks behaviour

Calling hg update with no arguments will move the bookmark to the tip.
Ends in the 2 side effects described above. It's even worse as there
are many tools that call bare hg update with no arguments like
TortoiseHG (unless you specify a target which is not the default).

Some other tools may do the same, for example to expose repositories
online (like redmine).

Proposal:

1. If the **active** bookmark is several revisions ahead than the
working directory and is in the same branch; then calling hg update
with no arguments should update the working directory **where the
bookmark is** and **not** at the branch tip.

2. If the **active** bookmark is in a different branch than the branch
of the current directory. Then hg update with no arguments should
abort with an error like "update would move to a different branch",
thus the user will need to call hg update with the bookmark name to
jump on the other branch.

3. If no bookmark is active at all, use the actual behaviour and do
not active/move any bookmarks at all.

Any comments are welcome

-- 
Demelier David