Menu
I am relatively new to source control in general and mercurial specifically. At my workplace we use mercurial. As is normal in a team, various persons work on different but related projects. The idea was to have one main repo (for project X) and subrepos for "child projects.
Implementing this is not an issue. But I was curious as to why in mercurial's documentation they consider using the subrepos feature, "a feature of last resort".
721
Subrepositories is a feature that allows you to treat a collection of repositories as a group. This will allow you to clone, commit to, push, and pull projects and their associated libraries as a group. This feature was introduced in a preliminary form in Mercurial 1.3 and has been improved steadily since then.
hg/hgrc will be created on the remote side. If the source repository has a bookmark called '@' set, that revision will be checked out in the new repository by default. To check out a particular version, use -u/--update, or -U/--noupdate to create a clone with no working directory.
It creates a kind of dependency that is right in a delicately balanced spot between too tightly dependent to keep in completely separate projects and too loosely dependent to keep in the same project. People often think they are in that sweet spot when they aren't, especially if they are accustomed to the folder structure of centralized version control. They don't remember that they crammed everything onto one repo to avoid the inconvenience of maintaining multiple centralized version control servers, rather than because of some intrinsic dependency relationship between the projects themselves.
57
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With
