Our team is just ramping up to use source control through SVN. We are currently using some test repositories for getting used to the process.
We’re nearly ready to put this into full time use.
We build only small to medum/large web apps, most of which share the same core (but differnt on LAMP/Win), but are customized in some way. We will likely have hundreds of projects in the repository. Also, we usually do more than one project for one organization.
We have LAMP and Windows developers. ( I think this makes the question somewhat different than Best practice for creating subversion repositories?)
Do you have any suggestions on how to structure the repository?
How you structure your repo will probably depend a lot on the release cycle. When you do a new version of your common core, will you roll it out to all your customers at once? Or will you do incremental roll-out as each customer needs new features (and, therefore, has need of the new features in the core)?
If you’ll roll out to everyone when you upgrade your core, then you probably want one set of branches/tags/trunk:
The downside to this is that, if there’s a lot of code for each customer, your checkouts would be huge, and you’d have to check out everything to be able to do anything (though svn 1.6 does give you the ability to check out a subset of the tree).
On the other hand, if the different customers will be released on different schedules, then you might prefer to have a top-level directory for each customer. You’d also want someplace to keep your common core.
If you do this, you’d probably want to look into
svn:externalso you get a copy of the common core whenever you check out customer1’s source tree. This causes some issues when you want to branch or tag, though. (Which might be a reason to prefer the first option.)If you haven’t yet, read “Pragmatic Version Control Using Subversion“. They have some examples of using externals, which might help clarify which scheme you want to use.