Mercurial Workflow: Feature seperation via named branches

Sébastien Deleuze seb at deleuze.fr
Wed Jun 15 18:40:55 CDT 2011


Hi,

Since we began to use Mercurial on a lot of projects in my company, we had a
lot of discussions and tries about on this subject, trying branches,
bookmarks or mixed usages.

We began by using branches with close branch feature. We had mainly 2 issues
with that :
 - we develop big projects with branch per feature strategy, so getting 2000
or 3000 features when developping a big application from scratch is not
unusual. With by design performance issues with too much branches, we
consider this as an issue for our use case
 - Close branch is a nice feature, but we had some issues. We usually want
to check that the merge is ok before closing the branch. So the workflow is
not really easy and produce an artificial head for the close commit. Having
thousands of these close commit heads is quite bad when viewing your grah
log
   $ hg up default
   $ hg merge feature-x
   $ hg ci -m merge
   $ hg up feature-x
   $ hg ci -m 'Closed branch feature-x' --close-branch

So when we saw bookmarks improvements (push/pull bookmarks on remote repo
and track current behaviour activated by default), we decided to use named
branches for main versions only (less than 10 long term branches) and use
bookmarks for our one branch per feature strategy.

We encountered 3 issues :
- Mixing named branch and bookmarks confused some users that loved Mercurial
for its simplicity (compared to Git).
- Have to specify -B to push/pull has never been understood by users. Git
has a strategy of pushing/fetching only one branch so this behaviour makes
sense, but since Mercurial make things easier by pushing/pulling all the
repo, people did not understood this behaviour. Perhaps it was just a
security to avoid side effects for this new feature ?
- The biggest one (and I am really interestd by feedbacks from people using
bookmarks in real life projects) : bookmarks (in their current behaviour)
were unusable as soon as 2 people worked on the same bookmark at the same
time. I don't remember all the details, but basicaly when the userA commit
on bookmarkXYZ on its local repo, pull changes of userB that made other
commits on this same bookmarkXYZ from a remote repository, he had 2
desynchronized bookmarkXYZ (not sure at 100% but we had a bookmark desync
issue).

So we switched back to the classical named branches, even if it has
drawbacks ...

Is this last point about 2 users using the same bookmark :
   - A bad use of this feature because we missed how to correctly use it ?
   - A bug encountered by outher people than us ?
   - A by design behaviour, so there is nothing to fix !

We came to the conclusion that there are some potential improvements that
could make light branching better under Mercurial.

Bookmarks improvements :
 - Fixing the bookmark main issue previously described, if this is a bug
 - Push/pull by default bookmarks without -B

Named branch improvements (I am not aware of Mercurial internal design so I
don't know if my proposals make sense or not, it is mainly a user need) :
 - If possible, implement some optimisations in order to make closed named
branches have no impact on performances
 - Allow users, after a merge, to do at the same time a "merge branch2 in
branch1 and close branch2" operation that would appear as a single commit in
the graph log.

Any thoughts ?

On Wed, Jun 15, 2011 at 10:17 PM, Benjamin Fritz <fritzophrenic at gmail.com>wrote:

> On Wed, Jun 15, 2011 at 12:51 PM, Matt Mackall <mpm at selenic.com> wrote:
> >> 2011/6/15  <mercurial-request at selenic.com>:
> >> > Also, I think you underestimate how badly things can go
> algorithmically
> >> > for people who are not aware that particular things aren't designed to
> >> > scale. For instance, we've had people who've tagged essentially every
> >> > commit in a 100k cset repo. That's simply not going to work well and
> >> > we're not going to be able to tweak things so it does.
> >> >
> >> I'm curious about what problems might arise from tagging nearly every
> >> commit. For instance, Vim is maintained in Mercurial at
> >> http://code.google.com/p/vim , and each new patch added is tagged with
> >> the patch number. What specific problems might occur from this
> >> practice?
> >
> > Slow startup for any command that needs tags info is the primary risk.
> > This is cached now so it's generally fast, but the cache will need to be
> > rebuilt at each tagging point. You probably won't see any pain here for
> > a long time.
> >
> > You seem to have an unusual model:
> >
> > changeset:   2891:acda456c788a
> > tag:         v7-3-219
> > user:        Bram Moolenaar <bram at vim.org>
> > date:        Mon Jun 13 02:04:00 2011 +0200
> > files:       src/os_mac_conv.c src/os_macosx.m src/version.c src/vim.h
> > description:
> > updated for version 7.3.219
> > Problem:    Can't compile with GTK on Mac.
> > Solution:   Add some #ifdef trickery. (Ben Schmidt)
> >
> > It seems like you bump the version number in version.c on basically
> > every change, then tag it as a release.
> >
>
> Yes, this is the case. It is somewhat strange (especially in the
> open-source world) but it is what it is. Bram is the
> benevolent-dictator-for-life of Vim and still maintains it by
> accepting patch files from Vim community (in pretty much any format
> but normally in Mercurial's nowadays) and then releasing each coherent
> change as a patch which he also happens to apply and keep in
> Mercurial. The nice thing is that within Vim's internal scripting
> language you can check for not only a specific version but also a very
> specific "patch level" using something like "v:version == 703 &&
> has('patch219')" for the specific changeset you quote. Due to this
> release strategy, it's convenient to be able to refer to specific
> changesets by version ID. But since there are not a bunch of
> intermediate changesets, tagging each one still only results in a few
> hundred tags per major version, rather that the hundreds of thousands
> you indicated would cause a problem.
> _______________________________________________
> Mercurial mailing list
> Mercurial at selenic.com
> http://selenic.com/mailman/listinfo/mercurial
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://selenic.com/pipermail/mercurial/attachments/20110616/2cae0b3d/attachment.htm>


More information about the Mercurial mailing list