My company has a large Subversion (SVN) repository, and for various reasons, we are considering migrating to Mercurial (HG). I'm hoping to learn the "best practice" ideas for our situation.
Our SVN repository is fairly monolithic, and looks something like this:
- trunk
- Python_Project_1
- Python_Project_2
- Python_Shared_Code
- Flex_Code
- ObjC_Code
- ...
- branches
- Python_Project_1_Release_1.0.x
- ...
- tags
- Python_Project_1_Release_1.0.0
- ...
Currently, we are the only consumers of any of our code & other resources in the repository but part of the reason for the switch is that we may/will be sharing some portions of our code with other consumers. So, our projects will be divided into the following categories of accessibility:
- Private Code (available only to us)
- Shared Code (shared with non-public partners)
- Public Code (shared via an open source license)
Also, to highlight the point, some code (e.g., the Python_Shared_Code folder in the SVN repository example above) is shared across projects, and so should be easily available to any Python projects (Private Code), and may need to be available for external consumers (Shared Code or Public Code).
I have some ideas of how I think I would lay this out, but I'd like to get outside ideas before continuing with the migration.
Update: I'm not sure it was clear from the above, but in particular, I'm looking for suggestions regarding the layout of HG repositories and how they interact.
Update: This question is similar -- but not identical -- to a few other questions that have been previously asked:
The major difference from the previous questions is the idea of "accessibility" and shared code. Some of the projects are inter-related (e.g., Python_Project_1 and Python_Shared_Code), and some may need to be shared with external entities (i.e., Shared Code and Public Code). The concept of splitting a single monolithic SVN repository into multiple HG repositories has been discussed, but I haven't found any concept of either type of sharing previously discussed.
I'd say this answer does a great job suggesting separate repos per module.
And in this answer I suggest using either subrepos (which are ready) or (my preference) a build system that pulls in dependencies from a local build box such as ivy.