How to maintain source versions and project tree structure in source control repository

Question

For a team of 4-5 developers using Visual Source Safe(VSS) 2005 what is best practice to maintain source versions?

Our requirement is to maintain and identify a version that is currently in production. This way at all times we will know what piece of code was pushed during deployment.
So far this is what I had in mind.

-trunk - Main solution and project
-Dev branches - branch created for development and enhancements

-Dev (some enhancement)  

-Release - release branches

-Release 2.1.0  
-Release 2.1.1  
-Release 3.0

Everything that starts with a dash(-) above is a folder in the repository.

I am thinking that each time we need to make an enhancement to our project, we make a dev branch from the main trunk of the entire project. This will be where the developers will work on. Once development is complete and UAT is done we proceed to the deployment.

After the project(in this case a web application) is deployed and confirmed that it is stable we make a Release(version #) branch of the Dev branch above. Lets say this is Release 3.0, we now know that in July 2010 deployment we pushed the code in the Release 3.0 folder.

We then merge(is this easy in VSS2005) the Release 3.0 code with the trunk. This way the trunk is always the latest deployed code and the next enhancement will be branched from trunk.

HotFix

Some things that I have not yet figured out is what happens when there exists a Dev branch that is being worked on and there is a hot-fix that is needed to be deployed immediately.
Perhaps, we make a separate branch from the latest Release folder, call it Hot-fix 3.0. Have the developers make the fix, merge it with Release 3.0 code after deploying the hot-fix and then merge with trunk again.

Clean up

After release there is really no need to have the dev branches. Should these be deleted?

Since we are branching, I read that in VSS deleting a branch does not free up the space in the database unless the original is deleted.

How should we delete, or should we delete the dev branches?

These are my thoughts, how do you manage your versions and what are your recommendations for my requirements.

We MIGHT be moving to TFS in the future, so anything I implement now in VSS should consider this move in the future.

Answer 1

Hello,

• trunk -> should only contain stable code
• tag -> add tags to the trunk code to identify versions (e.g. releases 2.1.0, 2.1.1, 3.0, etc.)
• branch -> create a branch for every single issue
• update -> update branches often to keep the code as close as possible to the trunk (because meanwhile other fixes where committed)
• merge -> merge branches to trunk if the solution is stable (include the issue number so the code changes are related to the issue number)

Most important of all:

• use a source control system which supports you in doing all this -> VSS will not ;)

Also take a lok at this interesting article: http://betterexplained.com/articles/a-visual-guide-to-version-control/