title: Defining boundaries in terms of repositories
body: <p>I'll set the scene first...</p>
  
  <p>We use Subversion and currently have a reasonably large Main repository. I'm looking to break it down though, with the possibility of moving to Git at a later date. The reason being is that a) Git can't do subfolder checkouts so favours smaller repo's, b) we can use branching a lot more (branch per feature).</p>
  
  <p>We have a web application, and also a web automation application.</p>
  
  <p>They don't directly depend upon each other in terms of code. But the automation app depends upon the web app in terms of design. If a change is made in the web app it could break the automation app.</p>
  
  <p>I'd like to split them into separate repo's, but a good point was raised. It's handy to have them under the same repo, so you know that at a certain revision they both worked together. </p>
  
  <p>Figuring that out with two separate repo's, with two sets of revision numbers is obviously quite tricky. The other problem is we have a number of apps (not just the automation one that depend on each other, API's etc...).</p>
  
  <p>Just wanted to see people's thoughts. If you've dealt with such an issue? Do you think they should or shouldn't be split etc... Do you use some sort of deployment tool to track the various revisions of each repo working together etc...</p>