[issue1716] manifest file gets (very) large with frequent branch jumps

[Greg Ward]

New submission from Greg Ward <greg-hg at gerg.ca>:

Certain workflows appear to have a high space penalty with Mercurial.  In
particular, if usage is characterized by frequently switching from branch to
branch, the manifest file can get very large.  This is most obvious when
converting with the --datesort option from a legacy VCS with many branches and
concurrent activity on multiple branches.

For example, if the association between revision numbers and branches looks like
this:

  [...]
  1000       default
  1001       default
  1002       v1.0
  1003       v1.1
  1004       default
  1005       v1.1
  1006       default
  1007       v1.1
  1008       v1.2
  1009       default
  [...]

then I think the manifest file will be much larger than it would be if you stuck
to one branch for a while and switched branches less frequently.

For example, at work I'm converting a 9-year CVS history with ~26,000 files and
~100,000 commits.  Using 'convert --datesort', I get a ~4.6 GB manifest file;
without --datesort (ie. using the default toposort algorithm), it comes out ~130
MB (if memory serves).  That's something like a 40x penalty for accurately
reflecting the chronology of our CVS history.  And with DVCS, space penalty ==
time penalty, at least for cloning.  (And for the first commit in a new
hard-link clone.  Dunno where else such a huge manifest will affect performance.)

This wouldn't be a huge concern if it only applied to converted repos.  But
would it also affect a frequent-branch-switch workflow that used Mercurial from
day one?  I see no reason why it wouldn't.

----------
messages: 9831
nosy: gward
priority: bug
status: unread
title: manifest file gets (very) large with frequent branch jumps
topic: performance

____________________________________________________
Mercurial issue tracker <mercurial-bugs at selenic.com>
<http://mercurial.selenic.com/bts/issue1716>
____________________________________________________