On Sep 9, 2013, at 07:31, Les Mikesell wrote:
> On Sun, Sep 8, 2013 at 8:13 PM, Trent W. Buck wrote:
>
>> I'm stuck. Since it's no fun to have tens of thousands of empty revs
>> in each project repo, my current approach is to leave existing
>> projects in the monolithic repo, and new projects get separate repos.
>
> Why do you think an empty rev will bother anyone any more in a
> per-project rev that having the rev number jump from a commit to an
> unrelated project does in the combined repo? It shouldn't be a
> problem in either case. Rev numbers for any particular use don't need
> to be sequential, you just need to know what they are.
This is true. Heck, if you use a dvcs like git or hg you'll get a completely
random revision number (shaped like a sha1 hash) every time. As someone used to
Subversion's usually sequential revision numbers, that bugs me aesthetically,
but it works fine.
There are also some reasons why keeping the revision number from the old
monolithic repository in your new repositories (with empty padding revisions in
between) is a really good idea. Have you ever referenced revision numbers in
your issue tracker ("fixed in r111"; "r222 broke xyz") or in emails ("can you
explain what you did in r333"; "r444 is a great example of abc") or in commit
messages ("reverted r555"; "added file forgotten in r666")? If so, you don't
want to renumber revs, because that would invalidate all those references.
