|MINI-HOWTO:
|1) Cheching in stuff on the main trunk: new features, bugs on new code, etc
| a) checkout jboss module (cvs co jboss), no tags
| b) do your changes
| c) commit them
| d) [optional] tag them
| Beware that cvs update -A (resetting sticky tags) is somehow less safe
|than a fresh checkout: CVS will not delete files you have in your local
|directory if they have been deleted from CVS (in a previous commit), so you
|end up with a mixed set of files.
|
|2) Checking in a patch on the "stable" branch
| a) checkout jboss module specifying the branch tag (cvs co -r 2.1_Stable
|jboss): this will checkout the *top* of the branch (ie the most recent
|changes to that branch). This is normally reason of confusion: you're not
This is a bit obscure to me.
Say the version is 2.1.5 (it is in one of the files) and the tag in cvs
2.1.5
To get the branch out on my disk I say
cvs co -r 2.1_Stable jboss? or
cvs co -r 2.1.5 jboss?
In other word the "Stable" is an alias for the latest one?
If not then you need to know the latest version before checking out, which
is workable but a source of much confusion I am sure.
|checking out the code at the moment of the branching, but the most updated
|one.
| b) do your changes
| c) commit them
| d) [mandatory] tag the branch, incrementing the patch number (cvs tag
|2.1.16 for example); this is vital to have easy merges to the main trunk
Ok so we "tag" the cvs with 2.1.16 AND the file with version=2.1.16???
Is cvs tag AND version overkill??
Do you use this yourself?
marc
| e) [mandatory] merge the changes to the main trunk if they're
|missing. Of
|course if other developer already fixed this on the main trunk as part of
|other changes the merge is not needed (but checking if it is needed is
|mandatory)
| f) [mandatory if e) was done] checkout the latest main trunk
|code (cvs co
|jboss), no tags
| g) [mandatory if e) was done] tag the main trunk (cvs tag 2.3.28 for
|example); this is also useful to track which files and when have
|been merged
|and if something went wrong we have tags to figure it out.
|
|3) Creating a binary (IMHO this is best done from branches)
| a) checkout the latest branch code, as 2a above (cvs co -r 2.1_Stable)
| b) run all the test
| c) tag the branch with an even minor release (cvs tag 2.2.0)
| d) if the even minor release is less than the current minor release on
|the main trunk, do nothing; else
| I) checkout the latest main trunk code (cvs co jboss), no tags
| II) tag the main trunk with the successive odd minor release (cvs tag
|2.5.0)
| For example we have 2.1_Stable on branch and 2.3.x on main trunk; we
|add lots of bug fixes on the branch; we create binary 2.2.0; we add more
|patches on the branch, until 2.2.85; then another binary is needed, so we
|create 2.4.0 *on the branch* *AND* we tag the main trunk with 2.5.0.
|
|Any comment ?
|
|Simon
|
