Bookmarks with hg update question
Scott Palmer
swpalmer at gmail.com
Tue Jun 28 22:32:17 UTC 2016
On Jun 28, 2016, at 3:10 PM, Jensen, Aaron <ajensen at webmd.net> wrote:
>> Here is a test case where the bookmark does not jump to some unrelated branch when I execute ‘hg update’
>
> You're correct that hg update doesn't take you to another branch. Unfortunately, that's not the problem. The problem is when the bookmark you're working on is on the same branch as your stable code base, which is illustrated by your final example.
>
> When I create a branch, Mercurial tells me:
>
>> hg branch feature_a
> marked working directory as branch feature_a
> (branches are permanent and global, did you want a bookmark?)
>
> This implies that branches and bookmarks are equivalent, except that bookmarks aren't permanent.
No, it does not. That would be reading in far too much to "did you want a bookmark?"
It is suggesting an alternative mechanism, true, but the implication that the *only* difference is the permanence is something you are adding.
> I think the problem is we're seeing bookmarks as two different things. I see them, and Mercurial itself tells me, that they are equivalent to branches. I think you see them as a non-global, personal, never-shared branch.
No. My workflow requires both shared and private bookmarks. I do not think of them as branches. I think of them as a means to track lines of development distinct from branches.
> In that case, it kind of makes sense that the bookmark would move.
When you read a book you move the bookmark. I find it natural that a bookmark generally advances but you can force it to go wherever you want. That's what happens with actual bookmarks that mark pages in a book.
> But I have to squint really hard and that hurts my eyes. (Don't current versions of Mercurial also push bookmarks by default so they are global?)
Not by default, you need to "hg push -B somebookmark"
> Even if they are non-global, personal, no-one-will-ever see them, I would prefer to move them myself, by merging the tip of the current branch into my bookmark.
What is the "current branch" in this context? The terminology is getting confusing.
To merge onto your bookmark it would be active, so the current state of the working copy would have the bookmark as the parent. So you would merge some other changesets, how are they "current"?
> I want bookmarks to behave just like branches, except for not being permanent.
But that isn't really what they are. They are a tool to help use unnamed branches like that.
> Every feature we develop currently requires a permanent branch. Everytime we push, Mercurial sends every single head to the server. We have so many branches on occasion we actually exceed the HTTP maximum header size.
You should push using a branch name to limit what gets pushed. I'm not sure if that would help with the header size.
> We've had to create a daily job to close and merge the heads of dead branches so we don't encounter this problem. Bookmarks, if they really behaved like branches and also weren't permanent would solve this problem.
I am using bookmarks as they are now to solve this problem.
Features start from the '@' bookmark, where you will naturally be after a clone. The first step is to activate a new bookmark for the feature. To share the feature with others we push the bookmark with "hg push -B myfeature" to a non-publishing repository. When the feature is complete we update to the '@' bookmark and merge in using the feature bookmark to say what we are merging. Then we push the new '@' bookmark to a publishing repository and pull or push those changesets back into the non-publishing repository.
That workflow enables history editing and all the fancy changeset evolution stuff while the feature is in progress, but keeps the main line stable.
But I must say I do agree that the update behaviour can be improved. I don't like how it can move on top of another feature so easily. If it didn't update past the '@' bookmark that could be improved.
Cheers,
Scott
More information about the Mercurial
mailing list