hg, git, fossil, ...

[Ian Kelly]

On Thu, Aug 28, 2014 at 10:17 AM, Marko Rauhamaa <marko at pacujo.net> wrote:
> In large repositories (like CPython), you have independent modules with
> relatively independent (and typically linear) histories. Hg and git
> don't want to respect that independence.
>
> As I said before, the problem is alleviated or goes away if you split
> your large repositories into tiny repositories. Then, looking at the
> example above, you could have a collections repository. CPython 3.0 and
> 3.9 might use the same version of the collections component. The bug
> would then be fixed in collections and both CPython 3.0 and 3.9 would
> simply update their component dependency to the latest and greatest
> collections.

So then to tag or branch a release I guess you would create the same
tag/branch on every single component subrepository?  And when you need
to checkout that old version you checkout every subrepository
independently. Sounds painful, but not unworkable.

But then what do you do if you need to checkout an intermediate
revision of the project that isn't tagged? This need does arise. You
can't just checkout the revision you want of a particular component,
because that old revision of that component may not be compatible with
the other components at HEAD. Even if it is, you're still checking out
a version of the repository that never actually existed. You can't
expect to reproduce behavior at a particular revision if you can't
even consistently recreate the revision.