0
votes

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.

1
Hmmm, seems like you could just do a dry run with hg-svn?Kzqai
Sorry, apparently I didn't make myself clear. I'm not actually worried about how to do the migration, but more about what the post-migration layout looks like. I've added an update to the end of the question to clarify.Chris Phillips
As you note this is pretty clearly a duplicate question, and the other askings have some good answers that completely cover your case. If you find they're insufficient, perhaps link to them and say how your situation differs. As is you're just going to get a lot of copy-paste answers from the dupes, and eventually someone will close this.Ry4an Brase
Thanks for the comment. I've added a clarification to the question explaining why I think this is distinct from previously asked questions. (If it is a duplicate of a question I haven't found yet, a pointer to the original question would also be useful.)Chris Phillips
Thanks for the clarification. I'll chime in below.Ry4an Brase

1 Answers

1
votes

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.