On Wed, Sep 11, 2013 at 10:49 PM, Nico Kadel-Garcia <nkadel_at_gmail.com> wrote:
> Les, disk space isn't the issue for the empty revs. It's any operations that
> try to scan or assemble information from the revisions. 5000 empty "objects"
> is still a logistical burden, especially if assembling any kind of change
> history for the new repository.
I don't see how that imposes a bigger computational burden than the
same number of unrelated revisions did in the combined repo. - which
typically is not a problem. We are at rev 186767 on a large
multi-project repo which, although I wish it had been created as
separate repos for easier future maintenance, does not have serious
performance issues.
> And since the new repositories are
> effectively a rebase of a subset of the code, you don't normally *gain*
> anything from having empty revisions for code that is in the other new
> repositories. You can't meaninglfully merge content between the new smaller
> repositories and the old repo, barring some seriously weird cases, so it's
> safer to treat them as completely distinct and not bother to preserve all
> the empty revisions.
>
> The "revision numbers are stored in support tickets" is the only reason I
> can think of to keep them.
Or pegged externals if they stay in the same relative location. Or
any email, documentation or recorded discussion referring to the
changes in a revision. My point is that any change that requires new
training or human intervention to fix something is never going to win
back that time. Someone who completely understands the current
process and user base might be able to optimize and improve it with
drastic changes, but that seems unlikely if they are asking for advice
on a mail list.
--
Les Mikesell
lesmikesell_at_gmail.com
Received on 2013-09-12 17:13:57 CEST