TODO: Needs clean up and formatting

   The goal is to have stable code only in the trunk, that allows QA team to start testing early ( thus milestone releases can be shorter because development and QA teams would work in parallel ), and does not enforce developers and QA team follow to moving target. Also, development code used by some third party developers, so code in SCM should be as stable as possible. Only fixes for QA and community issues, that can be done in short time, should be allowed directly to the trunk. Any new features should be carefully tested before commits, and continuous builds should never fall.

   At the same time, we should avoid to keep uncommitted code on the developer machines:

• First, there are no absolutely reliable hardwire and software in the real world, so keeping unchecked code locally increases risk to lose whole work. Often commits allow to be sure that any work could be restored easily from server.
• The second, rare commits evaporate SCM advantages ( changes history, availability to rollback errors ).
• The third, uncommitted code not available for others to review and collaborate.

To aim that goal and using svn at the same time, there is common workflow named 'feature branches'. I'll not describe it there in details, just provide some links:

• http://blog.gravityfree.ca/2009/02/using-feature-branches.html
• http://chestofbooks.com/computers/revision-control/subversion-svn/Feature-Branches-Branchmerge-Commonpatterns-Feature.html
• http://svnbook.red-bean.com/nightly/en/svn.branchmerge.using.html

In a few words,  team creates branches based on features. In this case, you create a development branch, perform work in the development branch, and then merge back into your main source tree. There would be separate branches for work on specific features, so they can be completed in parallel.

In this case, only finished jobs merged into the trunk code, so nobody has to follow moving target and make changes in his code during feature development. Developer could not worry about code stability before commits ( doing deep testing only then branch is going to be merged into trunk ), and unfinished features can be simple postponed for next milestone release. At the same time, all SCM features are available in the branch, and code visible by others for review or collaborate.

For component development, the process would be performed in these steps:

1. Implement base requirements for component, sample application and unit tests in the sandbox or development branch.
2. Commit component and related code into the trunk. Tell QA team that component is ready for testing ( by Jira task assigned to ... ).
3. QA team can start testing the component. All issues that will be found by QA, should be fixed immediately.
4. If the component has some additional requirements, they should be implemented in the branch. As that work ids done, changes should be merged into the trunk and corresponding task for QA created in JIRA.
5. If the significant changes were done to close to release date, they should be left in the branch to avoid 'last minute mess'.

How to deal with development branches:

1. straitforward way with svn clients. Svn has all capabilities to support feature branches, but...it's only available from the releases after 1.5. Unfortunately, Jboss uses outdated svn 1.4 server, that does not record merges, so "reintegrate" merging doesn't work. Hope IT staff at jboss will be upgrade svn infrastructure soon.
2. there is svnmerge script that does the same task as svn 1.5/1.6 with any version of svn. I tried it with Richfaces repository and it works well. The script shipped with command-line svn client and also available for download.
3. using distributed SCM systems ( git or mercurial, with git-svn or hgsubversion extensions ) as svn clients. Actually, it seems as the most comfortable way but hardly possible with Richfaces repository because they clone whole history, that is pretty big for so mature project as richfaces is. Also, there are some brocken changesets in the history, so using git or mercurial only available if IT staff could repair repository.