Hey,
see below.
> |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?
With the first command you get the top of the branch, ie the latest code,
the newest commited (even if the top of the branch is not tagged)
With the second command you get a version that has a symbolic tag of 2.1.5,
which has nothing to do with the *revision* number of the files, and may not
be the top of the branch.
I stuck with the <major>.<minor>.<patch> format cause it seemed to be the
most liked here.
Personally I don't use that. We have tags such as Rel_2_1 and
Rel_2_1_Build20010307, etc.
> 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.
Whenever you branch you assign the branch a name, in our case 2.1_stable.
This happens to be also the tag you can use to retrieve the most updated
code on that branch. That's the reason why after branching is better to tag
the code at the bottom of the branch, ie the code at the moment of the
branch, with for example 2.1.0
>
> |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???
Well, I suggest to tag the whole jboss module, not single files or
directory. IMHO tagging only files or directories is messy, unless you're
knowing exactly what you're doing.
Imagine checking out the jboss module updating every directory with a
different tag to have the code you really want. Ugh !
To eliminate confusion between CVS revision numbers and our tags, we can use
the format <major>_<minor>_<patch> instead of the dotted version, agree ?
Was I clearer ?
Simon
>
> 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
> |
>
>
