I am getting ready to set up an SVN repository, and was wondering if anyone had a good example for a repo structure. I am currently thinking:
Development
.. Applications
.... App1
...... trunk
...... branches
...... tags
.. Database
.. Third Party
While this structure could probably hold everything we need, I would like to make it a bit more granulated. Any thoughts?
On
SVN provides tags to take a 'snapshot in time' of the source tree at a particular time (which you can use for releases, etc.).
But if you're intending to make your repository 'more granulated', maybe you should consider setting up multiple repositories.
Of course, within the 'trunk' folder, you should set up whatever normal directory hierarchy you would if you didn't use source-code control.
On
We've been strugling with this too.
We've found out that it doesn't take long until some shared libraries are part of multiple applications and you would want to have everything on the same version. Therefore we've decided to put everything we do in one single repostitory. We've been working this way for over 2 years now and find it very good to work with.
All configurations have pro's and con's but by having 1 full repository you can be (almost) sure that you have all files together at the right version. If you work with multiple trunk's there are tricks with virtual folders or links (I've forgotten the term) to make it link with each other, but getting back to the point where you were is very hard.
Just remember each config has pro's and con's, but for a not to large company I would suggest to put everything in a single repo with one parent folder.
On
My current approach is breaking the systems on logical application boundaries all under one repository.
For example, imagine a service that also has a test suite and a database
/project1/application1/
trunk/
Src
Test
Database
tags/
branches/
application2/
trunk/
Src
Test
tags/
branches/
This Allows us to have multiple applications assoicated with a project, but handle release control for each "logical" application boundary. Consider where/what your release control need are and set those as the location of the branch/tag/trunk structure.
I don't like the single trunk/branches/tags folder at the root of the entire repository, because I don't want to have the entire trunk checked out, nor do I want to mess with partial branch checkouts as a result. (You may disagree and your mileage may vary etc etc)
On
We always create a separate SVN repository for each separate "solution". This repository then just has a simple trunk, branches and tags structure.
Any dependent frameworks (where we control source code) then have their own separate repository. We typically then just include binaries (at a particular version) into any project using them.
On
Having a single repo for everything means that you have a pretty good chance of ending up with a huge repository pretty fast. Which means things can get slow and a bit hard to track as well. Obviously, it depends on your exact use case, but personally I'd opt for per-project repositories and using svn:externals where needed.
Actually, I'd opt for a distributed VCS over SVN if possible, but to each his own...
We started with a similar model, but found it to be a bit cumbersome. The main problem is that if you want to branch your codebase at a release, you have to go make branches for each component.
Instead, we've considered a scheme like the following:
I like having a separate repo entirely for 3rd-party stuff. Unless you plan to implement the full vendor-branching strategy from the red bean book, this will work well.