this is Jack from CollabNet, Codesion Cloud Services. First, thank you for being a Codesion customer!
You describe your situation in terms of "projects," but that's an ambiguous term, and Subversion itself hasn't any notion of it at all. The real consideration here is not Subversion per se, but your build tools and release policy. You want the configuration that best supports what you want to do.
For example, do all these apps and libraries release all at once? Completely independently? Some mix? Is that answer likely to change?
If they all release at once, then there's important value in making it as easy as possible to identify which versions of each app were released with which versions of other apps. That way, bug reports can be verified, fixes implemented, and patches merged all in a coherent, consistent way. To achieve this, I would not use the "/app/{trunk,tags,branches}" structure that several have suggested, but rather stick with the canonical
/trunk/app1 /trunk/app2 /tags/TAGNAME/app1 /tags/TAGNAME/app2 /branches/BRANCHNAME/app1 /branches/BRANCHNAME/app2
structure. This allows you to branch, tag, and merge the whole tree, all apps and libraries, in a single command:
svn cp URL/trunk URL/tags/TAGNAME
On the other hand, if these things are independent, then you're better off with
/app1/trunk /app1/tags /app1/branches /app2/trunk /app2/tags /app2/branches ...
This way, for example, tagging one app doesn't affect another.
In a mixed case, you can still achieve the coordinated branching (when it's appropriate), but you'll have to use branching from within your working copy, and perhaps sparse check-outs (if the working copies are large). Alternately, you can tag or branch the whole repository, even though the tag or branch has no meaning for most of it: Subversion tags and branches are cheap to store, and (if you use the URL-to-URL form of "svn cp") cheap to make; the only reason not to tag things with unrelated tags is, it confuses the humans. But that's a pretty strong reason, so a mixed model is best handled with the "app/trunk" structure, to avoid confusion.
You can find good examples of the "/app/trunk" approach in the Apache Foundation repository. All the Apache projects (including Subversion itself) are stored in a single Subversion repository. There are around 100 projects there, and although there are some interdependencies, they're all pretty much managed independently. You can browse around this giant repo (possibly the largest single Subversion repo in the public world), starting at the root of all ASF projects. There's some diversity in practice, there, but one good example is Subversion itself.
Also worth note: in so far as Subversion is concerned, you can always change this stuff. The "tags" and "branches" are really just copies; you're free to rearrange things as you like, when you like. But there are some cautions:
- It'll confuse the humans
- "Tree conflicts" (addition, deletion, moving, or renaming files or directories) can make later merges painful. The function of a merge tool is to save you work. All merge tools eventually, for a hard enough merge, punt the decisions back to the humans; the important question is how much they can get right without that. Tree conflicts cause current Subversion (1.6 or better) to punt way more often than you'll like. So, it's best not to rearrange top-level directories like these too often, and be prepared to intervene and clean up for any merges that cross such rearrangements.
