SVN project structure and branching strategy for multiple projects that sometimes overlap

Question

I am trying to come up with a solid SVN repository structure and branching strategy for a small team of four. We have four major and several minor projects in development at any one time, and there is often some overlap between projects. Our current strategy is totally inefficient and consists of having each of these folders (approximately 15 or so) under a single versioned "trunk" folder. This means whenever we branch, we branch all 15 projects (it takes around 20 minutes to update the working copy and pull down a branch, to put this into perspective).

The main concern is that some projects overlap, and it's not uncommon for a feature or task to require changing something in Project A as well as in Project B (all of these projects talk to the same database and use the same database tables; in addition they share a business layer so that changing a class in one project will affect the other), as the projects are all essentially related parts of one "umbrella" application. As an example, for the major projects there is basically:

• Project A: Front-end e-commerce site
• Project B: Back-end fulfillment/management system
• Project C: An unbranded copy of the front-end site (same thing minus CSS styles and with less functionality)
• Project D: Web Service API

A and B are intertwined, but B is a software-as-a-service application (we act as our own client) with C as it's front end for customers (A serves as the front end for our own company, since C is essentially A with less features and without company-specific details). D is only accessed by clients, but it's my ultimate goal to have A, B and C all use the functionality of D via web services (eating our own dogfood, basically).

We have just decided to go with a three-week deployment strategy (meaning we do a production deployment every three weeks) and our current SVN strategy is cumbersome and makes branching extremely painful.

With several projects having an overlap, would it make sense to keep them all under one project folder with the branches/tags/trunks format, or should we treat them as individual projects? Maybe combine some, for instance having the SaaS frontend/backend together, with our own site and the web service being separate?

Any suggestions or advice from people involved in similar projects would be great.

Answer 1

This sounds exactly like the projects in my company. We have the same problem, we silently gave up on using the same code base for everything and split everything into separate projects because it was easier to manage that way. If possible what you can do is also create separate projects for the common code that you have and then reference the dlls from those projects in all your other projects. I've done this latter thing in my last company and it works. It just means you have to remember to copy the latest dll into your current project if you make an update the common code.

Answer 2

I would try something like this:

D - Make this a separate repo. Include in other repos where needed using svn:externals.
B - Make this a separate repo. Include in other repos where needed using svn:externals.
A - Make this a separate repo, and it can be the trunk.
C - Use the same repo as A, but make this its own branch. Any features from trunk that you want to expose to clients, you merge into this branch from trunk.