hg, git, fossil, ...

[Marko Rauhamaa]

Ned Batchelder <ned at nedbatchelder.com>:

> I feel like I am misunderstanding you.  My summary of what you just said
> is, "I have two scenarios where my code went through different sequences
> of changes to end up with the same content.  I expect both of those
> paths will show the same history."  That sounds nonsensical to me, so I
> must be misunderstanding you.  The path the file followed (that is, the
> sequence of changes that made the file what it is), *is* the history of
> the file.

Not the file but the repository.

Imagine we have CPython 3.9. It might have an ancient implementation of
the deque. Then somebody realizes there's an embarrassing bug that
requires a simple fix in a C file. The fix is implemented in HEAD. Then,
it is propagated down to 3.9, 3.8, ... 3.0. You obviously couldn't use
"hg pull" for the propagation since hg would insist on propagating all
the unrelated features as well.

With TeamWare, Bitkeeper(?) and CVS the process is simple since they
retain the file scope. Propagating a fix from HEAD to 3.0 is equivalent
to propagating a fix from 3.0 to HEAD. After the pull/push, if you look
at the version history, you couldn't say which way the process went
since the pull/push operation itself doesn't leave a trace. (Well, in
CVS, it does, but that's bad.)

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.


Marko