Mercurial Workflow: Feature seperation via named branches

[Benjamin Fritz]

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.