Sign Up to our social questions and Answers Engine to ask questions, answer people’s questions, and connect with other people.
Login to our social questions & Answers Engine to ask questions answer people’s questions & connect with other people.
Lost your password? Please enter your email address. You will receive a link and will create a new password via email.
Please briefly explain why you feel this question should be reported.
Please briefly explain why you feel this answer should be reported.
Please briefly explain why you feel this user should be reported.
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”.
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.