hg, git, fossil, ...

[Marko Rauhamaa]

Ian Kelly <ian.g.kelly at gmail.com>:

> 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.

Where I work, we actually have "made a science" out of componentization.
The individual components are very similar to linux's development
packages. They are released internally and have their own life cycles.
In particular, they are not rebuilt when the dependent application is
built.

> that old revision of that component may not be compatible with the
> other components at HEAD.

You don't alter ABIs. Component versioning and interdependencies are
managed rigorously. Even ABI breakages could be handled should they
arise.

> 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.

Generally, components only go forward linearly. If your ancient
application version needs a fresh bug fix in a component, it gets the
latest and greatest component version. Branching is supported but has
yet to be needed.


Marko