Bookmarks usage survey

[Gregory Szorc]

On 4/4/2014 5:39 PM, Stephen Lee wrote:
> Hi All,
> 
> I would like to get a feel for how many people are using bookmarks,
> and how they use them.
> 
> 1) Do you use bookmarks? How do you use them/what does your workflow look like?
> 
> 2) Are they working well for you? Any pain points?
> 
> 3) If you don't use them, is there something preventing you? What do
> you use for feature branches instead?
> 
> I would really like to hear from some of the bigger players (Facebook, Mozilla).

I'm a Mozillian and I use bookmarks regularly (although I feel I'm in
the minority at Mozilla - people tend to use mq if they are using
Mercurial - a lot of people use Git and export patches to Mercurial for
commits).

I use bookmarks as feature "branches." Every time I develop a new
logical set of patches, I create a bookmark to hold them and commit
there. I'm a user of changeset evolution. I used mq for a while, so
instead of committing small "fixups" to existing patches and using
histedit to fold patches, I instead tend to treat my bookmarks as mq
patch queues: I use `hg previous` and `hg next` (formerly "gup" and
"gdown") to "select" the commit I'm interested in, make changes, then do
`hg amend`. This means I'm constantly having to run `hg evolve -a` to
deal with obsolete changesets. I would really like to break that habit
and use histedit more. I think. But, Mozilla's commit model (like
Mercurial's) is patch based, not head/merge based. We strive for every
commit to be standalone. So, the model of working on individual
changesets/patches one-at-a-time instead of producing a stream of
commits and resolving them to standalone patches later does seem to make
a lot of sense.

One pain point I have for bookmarks is that they can be advanced when I
don't want them to be. For example, https://hg.stage.mozaws.net/gecko/
has bookmarks tracking various Firefox repositories. You commonly want
to start at a known good changeset/bookmark and work from there.
Sometimes I `hg up central/default` (which is effectively a "remote
tracking branch" to borrow Git's terminology) and then commit, advancing
the bookmark forward. But I really didn't want to advance
central/default because it's supposed to be read-only! I have to
remember to `hg up central/default` then run `hg bookmark
my-new-bookmark` to ensure the "active marker" is something I really
want to advance. Yes, I could write an extension or hook to enforce
read-only bookmarks. I haven't gotten around to it. What I have done is
incorporated the "prompt" extension into my shell so the active bookmark
is printed. That way I tend not to make any accidental commits to the
wrong bookmarks. I would *really* like Git's read-only "remote refs"
feature here. I've tried a few extensions that provide this and have
even tried to expose it through extensions, but they don't seem to work
right or have bad consequences. For example, I'm pretty sure the naive
approach of exposing these "labels" as tags interferes with the tags
and/or branch caches and causes performance of my 200,000 commit
repository to blow up. Fortunately, there are patches under
consideration for 3.0 that should make this better.

I haven't used branches that much because they feel too heavyweight for
me. I don't want to deal with the issues of "stripping" the branch name
from changesets before I commit them to Firefox. I just want to update
to a bookmark, rebase on top of whatever head I'm landing on, then push.
Bookmarks are great for that.

I wish there was better tooling around `hg bookmarks`. e.g. I would like
to do `hg bookmarks --mine` to show all bookmarks that belong to me
(i.e. outstanding changes I haven't finished yet). I would like `hg
bookmarks --sorted` to show me bookmarks in DAG order so I can see which
ones are oldest and should be pruned, etc. I would like a mechanism to
easily see which bookmarks have been pushed already but I forgot to
delete (including to delete from the server). Yes, I recognize I can do
this with a revset query. I wish it were easy for servers to be more
intelligent about it too "oh, you 'merged' this bookmark, you should
delete the clutter."

I think the behavior of creating new bookmarks of the form "foo at remote"
upon pulling a divergent bookmark can be extremely annoying. I've had
some automated processes pulling repos only to end up with 100
variations of a single bookmark (foo at remote99)! I want a mode where the
remote bookmark is always used and these @remote bookmarks never come
into existence. Even better, the client can be intelligent and recognize
that the divergent bookmark was never checked out locally, so who cares
if it is divergent.

Bookmarks are working for me. I enjoy them much more than mq patches
(having the merges done more intelligently and supporting obsolescence
are the big differences here). However, there are still a number of pain
points that I would love to see worked out. I'm not sure where one
should draw the line between core support and extension territory,
however. As long as lacking in the core doesn't prohibit things like a
full implementation of Git branches with Mercurial (remote refs and
all), I think I'll be happy.