svn - How would you organize a Subversion repository for in house software projects?

Question

I work for a company whose primary business is not software related. Most documentation for using source control is written with a development team writing for commercial or open source projects in mind. As someone who writes in house software I can say that work is done differently then it would be in a commercial or open source setting. In addition there are stored procedures and database scripts that need to be kept in sync with the code.

In particular I am looking to get suggestions on how best to structure the repository with in house software in mind. Most documentation suggests trunk, branches, tags etc. And procedures for keeping production, test and development environments in sync with their respective sections in the repository etc.

Answer 1

Setting up SVN repositories can be tricky only in the sense of how you organize them. Before we setup SVN, I actually RTFM'd the online Subversion manual which discusses organizational techniques for repositories and some of the gotchas you should think about in advance, namely what you cannot do after you have created your repositories if you decide to change your mind. I suggest a pass through this manual before setup.

For us, as consultants, we do custom and in-house software development as well as some document management through SVN. It was in our interest to create one repository for each client and one for ourselves. Within each repository, we created folders for each project (software or otherwise). This allowed us to segment security access by repository and by client and even by project within a repository. Going deeper, for each software project we created 'working', 'tags' and 'branches' folders. We generally put releases in 'tags' using 'release_w.x.y.z' as the tag for a standard.

In your case, to keep sprocs, scripts, and other related documents in synch, you can create a project folder, then under that a 'working' folder, then under that 'code' and next to it 'scripts', etc. Then when you tag the working version for release, you end up tagging it all together.

Repository
   ProjectX
      Working
         Code       
         Scripts
         Notes       
      Tags
      Branches

As for non-code, I would suggest a straight folder layout by project or document type (manuals, policies, etc.). Generally with documents and depending on how your company operates, just having the version history/logs is enough.

We run SVN on Windows along with WebSVN which is a great open source repository viewer. We use it to give clients web access to their code and it's all driven by the underlying Subversion security. Internally, we use TortoiseSVN to manage the repositories, commit, update, import, etc.

Another thing is that training should be considered an integral part of your deployment. Users new to version control may have a hard time understanding what is going on. We found that giving them functional instructions (do this when creating a project, do this when updating, etc.) was very helpful while they learned the concepts. We created a 'sandbox' repository where users can play all they want with documents and folders to practice, you may find this useful as well to experiment on what policies to establish.

Good luck!