title: How to organize mercurial repository / subrepositories in large team project
body: <p>At work we need to regorganize our system of version control. </p>
  
  <p>The structure of the project is the following:</p>
  
  <p>2 teams: <strong>Team1</strong> and <strong>Team2</strong></p>
  
  <p>a) <strong>Both Team1</strong> and <strong>Team2</strong> work on module <em>A</em>.</p>
  
  <p>b) <strong>Team1</strong> also works on <em>B</em> and <em>C</em>, which depend on <em>A</em>.</p>
  
  <p>c) <strong>Team2</strong> also works on <em>D</em>, which depends on <em>A</em> but <strong>not</strong> on <em>B</em> and <em>C</em></p>
  
  <p>We don't want <strong>Team2</strong> to physically have on their local machines <em>B</em> and <em>C</em> (which belong to <strong>Team1</strong>) and at the same time we don't want <em>Team1</em> to have <em>D</em>.</p>
  
  <p>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. </p>
  
  <p>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? </p>
  
  <p>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 <em>A</em> with that of both <em>B+C</em> and, separately, of <em>D</em>?</p>
  
  <p>We are worried that such a manual tracking can be prone to errors over time.</p>