and similar, our methodology for source control must be refined.
This will require some adaptation and flexibility, and a bit more work initially, for several good benefits.
The project is a the top level. A Subversion repository is created with a title using the lowercase version of the project name. Then there is a set of directories that are recommended by the subversion red book, a warmly suggested reading.
Under trunk, each subcomponent of the project should have its own directory.
A work package is a set of tasks that make a cohesive unit. e.g. A set of bug fixes, a set of new functionalities, a new subproject (ex. RDPdb). In Redmine, these are issues linked from the same issue.
If a Work Package needs more than one working day, a branch is needed. The name associated with the work package is used to create a branch from the trunk
A developer may be assigned one or more Work Items and then will checkout the code from the Work Package branch that the Work Item is associated with. That is, there will be a branch created from trunk that has the same name as the Work Package, and all software changes will be made for that Work Package on that branch.
It is suggested that the developer removes the files from his local machine before that, or creates a new project on his local machine, in order to avoid mixing up the files of different branches.
The developer works on the software associated with the Work Item and checkin that software to the branch when a significant enough change has been made that he would not like to loose it, or he needs to share the changes with another developer. As a minimum, the code will be checked in at the end of the day.
There must be a unit test associated with the software module developed or modified and that unit test must be incorporated into the software build process.
Once that developer believes that that work item is complete, they will comment the checkin with the work item number and checkin the software.
Once all the work items on the work package are completed (all work items are closed), then the work package itself may be closed.
A work package may constitute a bug fix or a new or modified piece of functionality.
As work packages are continually opened, worked on, tested and closed the PM may decide at any point that the sofware is in a state ready to release. This is especially so if the build is continuously tested and they are sufficient Unit and System Integration Tests such that the PM can have a good confidence that the software is of good quality.
At this point a tag is created with the next release number and the branches chosen to compose the release are merged onto that tag. A release number is only associated with a tag, not a branch; branches have release names.
Release numbers will take the following form: X.Y.Z
Once tagged, that release is then ready for the QA team. The QA Team will take that tag and checkout all the software that constitutes the project and independantly rebuild the QA environment from scratch with only the software associated with the tag. This ensures that all the software associated with the project is in fact in source control. Once the QA environment has been built then the QA team will test independantly that release of the software.
Once the QA team believe it is ready, it will be passed to the Staging environment for business approval.
On business approval, support will install that build into production. Once it has successfully been deployed into production, the released tag is merged into trunk and trunk becomes the latest software released into production.
All current development work package branches must then be merged from trunk to make sure they are working on the latest production released software.
There is a more detailed explanation in the subversion red book.