On Wed, Sep 11, 2013 at 10:49 PM, Nico Kadel-Garcia <nka...@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 lesmikes...@gmail.com