How to organize mercurial repository / subrepositories in large team project

Question

At work we need to regorganize our system of version control.

The structure of the project is the following:

2 teams: Team1 and Team2

a) Both Team1 and Team2 work on module A.

b) Team1 also works on B and C, which depend on A.

c) Team2 also works on D, which depends on A but not on B and C

We don't want Team2 to physically have on their local machines B and C (which belong to Team1) and at the same time we don't want Team1 to have D.

The aim is to have complete snapshots of the project in time, i.e. we would like to keep track and rollback to a given version of the whole project at any time.

We thought of using Mercurial subrepos, but it seems impossible (maybe) for a team to ignore the subrepos of the other team. Everyone has to pull every subrepo. Is this correct?

If so, how can we overcome this? Do we really need to have three completely independent repositories and manually track the compatible version of code A with that of both B+C and, separately, of D?

We are worried that such a manual tracking can be prone to errors over time.

Answer 1

You could use subrepos and organize as:

• Team1 uses master repo X with subrepos A, B, and C.
• Team2 uses master repo Y with subrepos A and D.

If B and C are unrelated, you may want:

• Team1 uses master repo B with subrepo A.
• Team1 uses master repo C with subrepo A.
• Team2 uses master repo D with subrepo A.

If A changes the teams can choose if and when to update the A subrepo to the new change and commit it to their master repo.

Answer 2

It's easy for a team to ignore the subrepos of another team. They just need to use different branches in the parent repo, with .hgsub files that include only the subrepos needed for that branch.

I would suggest not having multiple master repos, but just one master repo with these three branches:

• Branch "Team1" has in its .hgsub file only subrepos A, B, and C.
• Branch "Team2" has only subrepos A and D in its .hgsub file.
• Branch "All" (or default) has A, B, C, and D in its .hgsub file.

When team 1 checks out from branch team1, they get A, B, and C. Team 2 checks out from branch team2, and they get just A and D. The manager of the whole project uses branch "All" (or default), and updates all repos A, B, C, and D to appropriate versions, then commits, to tie all repo versions together and get the complete snapshot that you want.