Hi,
> -----Original Message-----
> From: marc fleury [mailto:[EMAIL PROTECTED]]
>
> |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
>
>
> Say the version is 2.1.5 (it is in one of the files) and the
> tag in cvs
> 2.1.5
Oops - forgot that tags cannot look like versions. Tags must begin with a
letter and can't include dots - so the tag would be something rel_2-1-5 (and
rel_2-1-5_stable) and the file 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?
cvs co -r rel_2-1-5_stable
>
> In other word the "Stable" is an alias for the latest one?
Yep
>
> |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???
Nope the check in of a file automatically gives you 2.1.16 of a file (if you
have versions like that... but you don't)
Your just adding a rel_2-1-16 tag
>
> Is cvs tag AND version overkill??
Nope - you want to know the whole set of files and their versions for a
given release - which is what a tag defines.
> Do you use this yourself?
Yep - although I havn't had much branching... which perhaps explains my
wariness of creating more branches for binaries...
> | 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.
I don't think this is needed - tagging of the main trunk - cant this be done
by date just as easily. Just tag it when we want to make a release.
> |
> |3) Creating a binary (IMHO this is best done from branches)
[snip]
Now this seems like overkill - the branch is tagged already - so why not
just use that for the build?
Chris
PS
This definitely needs a HOW-TO on the website!
================================================================================================
This electronic message (email) and any attachments to it are subject to copyright and
are sent for the personal attention of the addressee. Although you may be the named
recipient, it may become apparent that this email and its contents are not intended
for you and an addressing error has been made. This email may include information that
is legally privileged and exempt from disclosure. If you have received this email in
error, please advise us immediately and delete this email and any attachments from
your computer system.Rabobank International is the trading name of Coöperatieve
Centrale Raiffeisen-Boerenleenbank B.A. which is incorporated in the Netherlands.
Registered with the Registrar of Companies for England & Wales No. BR002630 and
regulated by the SFA for the conduct of investment business in the UK.
The presence of this footnote also confirms that this email has been automatically
checked by Rabobank International for the presence of computer viruses prior to it
being sent, however, no guarantee is given or implied that this email is virus free
upon delivery.
