Need help with SVN: Trunk/Branches/Tags structure

Question

We are currently using SVN without Trunk/Branches/Tags structure. So far we were good with it but now, we have reached a level where we need some kind of system which can handle 3 different level of versions for 3 different servers.

Currently this is what we have been doing:

All the files in a single repository, once the work is done, data is committed to our development server, after it being tested, it's moved to staging server and after another round of testing, it's moved to the live server.

But in above process, there is very less room for us to work on the new feature and fix the minor issues simultaneously. So, to fix this, I thought, we can use Trunk/Branches/Tags structure where the latest development version can be stored in Trunk and deployed on our Development Server.

Tags can have the versions (e.g. 1.0.1,1.0.2 etc..) for the staging server and Branches will have the latest versions (e.g. 1.0,1.1 etc..) for the Live server.

Now, the problem is, currently all the development is done on the local server and I am not sure how I will get this structure working on a single server where all the developers will work in a single root folder.

Or should we make 3 separate root folders (Development, Staging & Live)?

Any kind of suggestions are welcome.

Answer 1

Your repository structure should be independent of your deployments; that is, it should have no references to staging, live, or anything having to do with where the code goes once deployed.

And the way you have described your version number system, they are both tags. Take a look at the branching and merging chapter of the SVN documentation for an explanation.

Answer 2

Our process contains three folders on the deployment server (though we sometimes split those three folders into three different servers): /dev, /test, and / (for prod).

In the repository, we work on new features in the trunk. Changes to trunk are automatically pushed to the /dev folder so we can see in real time what the site looks like.

At a predefined deadline date, we branch the trunk and name it test, and export the test branch to /test. We continue to develop new features in trunk while we fix bugs in the test branch, exporting each to their respective folders on the server and continuing to test the /test folder.

Once we are satisfied with test, we tag it with a public version number (like 1.2). Then we deploy that tag to / (the production folder). Then we merge the changes from the test branch into the trunk so that our bug fixes get incorporated. Then we begin the next cycle.