Subversion repo questions.

[trq]

Not really sure of the approach I should be taking here. Ive just inherited a large project (3.4G) which is currently maintained by 3 developers, using one subversion repository /trunk. There are no tags or branches.

 

Each developer has there own development server, there is one shared testing server and one production server.

 

The way things are done currently is as each developer finishes there work, they commit to the /trunk, the testing server's working copy (of /trunk) is then updated to the latest revision, the site is tested and if approved the production server's working copy (of /trunk) is updated.

 

The problem lies (I feel) in the fact that someone could make unfinished or not working commits to /trunk and break production.

 

What I would like to do is create a few tags, namely /tag/testing and /tag/release. The testing server would then use /tag/testing as its working copy (server root) while production would use /tag/release.

 

As I'll be the only dev able to write to /tag this will mean should mean that /tag/testing and /tag/release remain relatively stable.

 

However, I still end up with the same problem as before, I'm really not sure how to prevent unfinished work being committed to /trunk and then inadvertently making it into /tag/testing, this may also then be overlooked again and inadvertently make it into /tag/release.

 

Has anyone got any thoughts on the process? Any better ideas?

[gizmola]

thorpe,

  It sounds like what you really want is to have the developers work in branches. That is the only way that you'll keep things out of the trunk.  Eventually of course, branches have to be merged back into the trunk and this can be a problem with svn, especially if you have developers that aren't that savvy. If you do go this way, have the developers use http://www.orcaware.com/svn/wiki/Svnmerge.py to help with the merging process.

 

Personally, my feeling is that what you do is:

 

-Make a Release Tag for your current state of code.  Disallow any further trunk commits until you get this setup.

 

- Make a branch based on this "release" tag. 

 

-Have the developers work in the branch (again make sure they init their areas using Svnmerge.py). 

 

When you are in "Release Candidate Testing"  Merge into trunk and make a release Candidate Tag.  Your Continuous build/Test site can be setup to build from the RC.

 

During the RC period, you put bug fixes directly into the Trunk, so that you don't have to worry about merging.  Testing QA goes against this, and the continous build/ testing site should be building from the trunk.  How you manage this often depends on how rigid QA is (assuming there's a seperate group).

 

Whenever you have enough bug fixes to warrant another RC phase, make a new RC Tag.

 

Repeat until you have signoff.

 

When you do your production release, Tag production based on the RC (if you're rigorous about that process) or the Trunk, if you're greenlighting whatever the state of the latest build is. 

 

 

Next development phase -- make new branch off the release tag.

 

 

This process insures that you are always testing off a merged tree, so that you will never get post release merge regressions or abnormalities, whilest you also get the benefits of branches and tags for release mgmt and testing.

 

Also if you guys can afford it, I highly recommend Fisheye and Jira to get the most out of svn and bug fixing.  You can get everything tightly integrated, so that for example, developers working on bugs, commit with a jira bug id, and you'll have the jira case linked to the svn commit that fixed it.  Amazing stuff, when it's all setup.