First of all, the structure of a Subversion repo is just a directory tree. The use of 'trunk', 'branches' and 'tags' directories is just a community convention. As a any convention is better for you to stick to it, but not mandatory. That said, I use to have ONE repository for an application and inside this repo, the classic structure 'trunk', 'branches' and 'tags'. But if the application is big enough or have a bunch of modules you have two alternatives:
A: (For shared versions among modules)
trunk (module-A, module-B, module...)
B: (Versions will go independently for each module)
module-A (trunk, branches, tags); module-B (trunk, branches, tags)
The second alternative could be implemented using a single repository or multiple ones, on the SVN Book (link below) you have a description of each one and their benefits.
If you are not familiar with the usage of directories 'trunk', 'branches' and 'tags', here you have a brief description, but please refer to the SVN Book, and look for "Strategies for Repository Deployment" and "Recommended Repository Layout" sections.
- trunk: “main line” of development
- branches: divergent copies of development lines
- tags: named, stable snapshots of a particular line of development
How do I use them?
- The first project structure was uploaded to the trunk.
- Every time a new requirement or project comes we copy the trunk content into a new branch (with a representing name).
- We work on that branch until completion of UATs (User Acceptance Testing).
- After that, we reintegrate the branch with the trunk (merge). Note: if more than one branch is going to be released to production you have to do all merges before and ideally test the integration of all changes, using the trunk code.
- Finally we create a tag, to mark the release of this version to the production environment. Note: all tags are read only, no one on the team can change a tag after its creation. This simple rule ensures that you can go to a known stable version of the code if the some problem occurs.
In summary (and here are your key concepts):
- Read the SVN Book.
- Understand the basics of subversion
- Become familiar with all different projects structres alternatives and choose the one that better fit your needs.
- Become familiar with all different branching models, use the matching one depending on the work to do (a bug fix, a request for change, a long project, etc.).
- Understand what trunk, branches and tags are for, specially the last one.
- Understand what is a working copy, a repository, a revision, the cheap copy concept
- Remember not to version your binaries, only your sources. I made this clarification because of your actual layout you have things named "DLLxxx", so I'm assuming they are binaries (.dll files).
After the implementation, if you have troubles getting your partners to work with the tool, here is a possible reason of that behavior: Why developers don’t use a Version Control System (CVS, SVN, Git, Hg, ...)?, please leave your comments or experiences on getting a team on using a versioning tool.
