.hg directory has eclipsed 3GB - how to deal with huge manifest?

[Axel Hecht]

2009/1/14 marlborobell <marlborobell at gmail.com>

>
>
> bughound wrote:
> >
> >
> > Here are the stats:
> >
> > hg manifest | wc
> >   22111   22111 1332641
> >
> > hg log -qm | wc
> >   11648   11648  217141
> >
> > hg id -n
> > 25600
> >
> > hg heads -q | wc
> >       1       1      19
> >
> > hg branches | wc
> >       1       2      50
> >
> >
>
> I'm a colleague of bughound's and the person generally most responsible for
> the repo in question. One of the things about this repo is that we're using
> some tools (written by me) layered on top of hg that followed requirements
> of 'automated regressions with their own checkins, tagging of revisions,
> ignore the tip, but DON'T use multiple heads or named branches'. My
> suspicion is that if we'd implemented named branches properly (for
> advancing
> changes through a set of regression gates) we wouldn't have gotten into
> this
> mess. Unfortunately, we don't have the development time available for the
> next few months to fix these tools to go to named branches, although it's
> definitely on my to-do list.
>
> From a quick look at hg debugindex, a lot of our large changes are
> tip-merges, where we merge heads to ensure that we stick to one head (and
> only for that reason). Each of those appears to be of length 140K or so,
> but
> other changes (that are even bigger) can be as simple as commenting out one
> line. Linkrev 25616 is one such. (Providing I'm reading the output
> correctly, the 'linkrev' field of the manifest corresponds to the revision
> I
> can actually see when I type hg log. I'd love to know why there are a few
> small gaps in there...)
>
>  <http://www.nabble.com/file/p21462538/00manifest.i>


FWIW, at Mozilla, we're using single-head repos, too, and have made good
experience with mq for the most part.

If you can require hg 1.1 and beyond, using hg pull --rebase might do the
trick for you for the most part, too.

Axel
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://selenic.com/pipermail/mercurial/attachments/20090114/9a70e6f6/attachment.htm