Maintaining branches and tags in a multi module project that uses mercurial

Question

I'm working in a application with many modules each having it's own mercurial repository.

I initially thought it's good to have the modules in individual repositories but after a couple of releases, I feel something is not right. It's really a pain to create the branches and tags in all the modules.

Most, if not all modules follow a similar release cycle.

Should I go ahead and use a single repository for all the modules? Or is there a better way?

Answer 1

A single repository for all modules means they are tightly coupled in their development lifecycle:

• any branch applies to all modules (which is what you want)
• any tag applies to all modules (which maynot be what you want)

If "v1.2" for your software has any meaning for each and everyone of your modules, then yes, having them all within one repo is useful.

If some modules are at v2.4 while another is at v3.6, and another at "v4.5", and..., then having independent modules declared as subrepos is best.

---

Lasse V. Karlsen comments:

if you're sharing things, like components and general framework libraries, they belong in their own repositories

Which is right, since the development lifecycle of said components and general framework libraries is completely unrelated to the one of the main program

But the OP adds:

We have two sets of modules:

• a set of core modules that can be reused across many applications and
• another set of modules for the respective application

So some of those modules (the "set of core modules") can be kept as subrepos (independent repos referenced by the parent repo and main project).

The others can be merged directly into the parent repo (kind of like the git subtree merge strategy) with the Hg tip you mention: "Combining Repositories"

Answer 2

If all these modules belong to a single project they should have a single repository. The module code can be grouped in directories within a single repo.

[Edit: based on comments]

The structure looks like :

1. You have core modules ~ Platform
2. Various other apps / modules that utilizes the core modules.

In such a case, the platform or core module can develop at a different speed than app modules. It is better to segregate them into separate repositories. Initially, it does look enticing that they both may follow similar release cycle but in any typical platform / application development, they do go out independently and out of sync. At least that has been my experience.

P1 -------P2 ------P3 ------p4

A1------A2--------------A3--------- (A1, A2, A3 utilize platform P1, P2, P3..)

B1--------B2----------B3---------   (B1, B2, B3 utilize platform P1, P2, P3..)

A3------------------B3--------------