JBossTransactions Subversion Repository

The subversion repository contains four areas used by differing parts of the development process

• trunk

• tags

• branches

• workspace

trunk

This is the main area of development and likely to be the most fluid.  It can be used directly for small, incremental, development that is safe to share with the other developers.  This is the definitive area for the latest version of the source code.

tags

This area contains copies of all releases that have been made.  Each release should be copied into this hierarchy once it has been finalised, with no further development taking place within this hierarchy.

The immediate children of this area should be named after the release.

JBossProductVersioning has the naming conventions.

branches

This area is used for applying modifications to a release.  The original release should be copied from the tags hierarchy prior to development and copied into a new tag once released.

The immediate children of this area should be named after the name of intended release.

Modifications to community releases that don't warrant a full version increment generally use _SPX (service pack) branch suffix where X is a version number.

In addition, tags used for the platform builds may have a cumulative patch branch, named (tag)_CP. Release tags from that branch are (tag)_CPXX where XX is a two digit sequence number. Yep, that's different from service packs that don't pad to 2 digits. You can also have CP branches for service packs, which leads to nifty tag names like 42_3_SP1_CP02.

Note that the _SPX suffix replaces the _GA suffix on its parent release, whilst the CPXX suffix is additional. Hence AB_C_GA  becomes A_B_C_SPX (not A_B_C_GA_SPX) or A_B_C_GA_CPXX (not A_B_C_CPXX)

workspace

This is a scratch area that should be used for development which will be intrusive to the code base or which will take place over an extended period.  The modifications should be merged back into the trunk once complete and then deleted from this hierarchy.

The immediate children of this area should be named after the developer who creates the entry.  How entries are named below that level is up to the developer.