Mercurial Workflow: Feature seperation via named branches

Matt Mackall mpm at selenic.com
Wed Jun 15 12:51:24 CDT 2011


On Wed, 2011-06-15 at 12:30 -0500, Benjamin Fritz 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.


-- 
Mathematics is the supreme nostalgia of our time.




More information about the Mercurial mailing list