Bazaar Mercurial Plugin to access BitBucket

[David Muir]

On 10/21/2011 01:02 PM, Stephen J. Turnbull wrote:
> David Muir writes:
>
>  > I'm surprised nobody has mentioned Mercurial's named branches,
>  > bookmarks, anonymous branches, etc. Finally settled on using named
>  > branches for everything, as the others do a fast forward pull (if it
>  > can) when you try to merge back into default (trunk).
>
> Well, this is a thread about Bazaar's advantages.<wink/>

That's why I brought it up. I consider it one of Mercurial's weak
points. Bazaar IMO has the advantage here as the default is to merge
without fast-forward, but still has the option of doing `bzr merge
--pull` if you want that behaviour. With Mercurial there is no option to
merge instead of fast-forward, unless you're using named branches, in
which case, I believe you can only merge, and not fast-forward (haven't
actually tried, as it's not something I'd ever do).

>
> I really dislike Mercurial's named branches.  They're not branches in
> the usual VCS sense of "ancestry back to the root", but rather a
> partition of the nodes in the DAG.  I'm not even sure named branches
> are guaranteed to be contiguous sets, and I find it very disconcerting
> that fork and merge nodes are not part of both branches.  It *is* nice
> for forensics to be able to identify a branch's nodes after a merge.
> (This comes up if you close a feature branch, and then discover later
> that you need to do a bunch more work on it, but want to restart from
> the merged state.  git branch refs don't help you deal with this, and
> you can't even use the merge parent order to identify anything except
> the mainline.  I use a tag on the premerge node, which is suboptimal,
> but easy enough to apply during forensics if I didn't bother at merge
> time.)  But given the cognitive dissonance created by opposing named
> branches to "real" branches, I'm happy to forego the former.
>
> I also (as described elsewhere) think that deliberately introducing
> multiple heads into a model that isn't designed explicitly to manage
> multiple heads is confusing unless the project already has the right
> kind of workflow.
>
> A bookmark looks to be just what git calls a "branch ref".  It seems
> to me that this is the right way to manage multiple heads, but my
> project very carefully avoids multiple heads, so I haven't tried them
> in the context of Mercurial.
>

Bookmarks seem to be the way forward, but until they let me merge my
changes rather than pull, it's not much of an option for me.

David