Bookmarks with hg update question

[Jensen, Aaron]

> The downside of which is, of course, that it changes previous default behaviour 
> which, for very good reasons, Mercurial very rarely does, **Thanks Devs this makes 
> life a lot simpler**. 

I agree. Maintain backwards compatibility as much as possible. But I disagree that backwards compatibility should always win. I think this is a good exception to make.

What happens if this behavior changes? For those who like the current behavior, hopefully they'll get used to a new parameter on update that will move their bookmark (equivalent to `hg pull -u`). If not, moving the bookmark can happen with a merge or `bookmark -f` command. If they don't notice the bookmark stayed put when they updated? Worst case, they're puzzled because their code isn't where they expect it. Missing code is usually not destructive.

The reverse, I would argue, is potentially more harmful. If I'm using bookmarks as lightweight branches, and I'm working on a feature that isn't ready to be released, an inadvertent `hg update` suddenly puts my not-ready feature in a place I don't want it. Most likely, I didn't even notice my bookmark/branch moved. Yikes!


> Possibly a way to avoid confusion would be to have both 
> settings, or either with a true/false value, AND make the default action on every 
> update that would move a bookmark to prompt the user, preferably with a message that 
> also reminded them which setting to change to set their default behaviour.

Ugh. Don't prompt people. Most people won't even know what they're being asked. Very few people notice or pay attention to output messages. We've been using branches for years and nobody has ever asked if they should be using a bookmark instead. Also, what happens during non-interactive sessions, e.g. on build servers? If it is on a branch, and the build software just issues an `hg update` command (this is what our build software does), the bookmark moves and now the build server is building in the wrong place.


> For maximum backwards compatibility this could try to detect if it is being run from 
> a non-interactive session, (bat file or bash script), and in that case default to the 
> current behaviour but print a clear warning if it is moving bookmarks.

This puts more work on users. One of the reasons I love Mercurial is that it is simple and tries not to put work on users. If they forgot and ran `hg update` without arguments, they'll only know the bookmark moved if they read and understand the output, which most users don't. They may not even know what a bookmark is! If they do notice they've done something wrong, they have to know how to fix it. For the majority of users, this is not likely.

 
> Would it be possible in every bookmark move to automatically place a, possibly 
> temporary, bookmark at the pre-move position and mention its existence in the output 
> message? This would allow any inadvertent or erroneous bookmark moves to be undone.

This seems like too much work and bookkeeping. Just don't move bookmarks unless someone asks. Bookmarks and branches should be mostly interchangeable, since bookmarks are intended to be lightweight branches. Replace the word "bookmark" with "branch" and you'll see the current behavior doesn't make sense. Branches tips moving on an update? Yikes!