[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: CVS Tagging and Releases
From: |
Todd Denniston |
Subject: |
Re: CVS Tagging and Releases |
Date: |
Mon, 10 Apr 2006 07:41:14 -0500 |
User-agent: |
Mozilla Thunderbird 1.0.7-1.1.fc4 (X11/20050929) |
Liquidchild wrote:
Guys,
Can you help!
I am trying to figure out the best way of doing the following...
We implement multiple code changes within a weekly release that is
tagged. However say 9 of the 10 code fixes pass UAT but one fails, we
want to regress to the previous tag version for the files that failed
only. I know that it is possible to revert back to another tag, but
this still maens that the current tag would exist in the repository for
that file, and future check outs of that tag would result in failure
when running the code. We basically want to be able to move the
release to live with only the code changes for the 9 code fixes. Would
it be better for a developer to individually tag the files that they
have changed then have another tag for each release to live?
For what you are describing it sounds like having each developer tag the
baseline when they do a commit, or if a commit info script could do
it(possible race conditions), that would make it easier to deal with. I would
suggest making a script for the developers to run so that they always tag the
whole repository instead of just the files they changed. it may be better to
make the script a wrapper around `cvs commit` so that the commit and tag are
done in the correct order.
You _might_ find the script in the following email useful to determine the
base dir that the tag needs to start in.
http://lists.gnu.org/archive/html/info-cvs/2005-11/msg00323.html
Would
this make it easier to pull a deveoplers change?
yes, if you have a tag DEV_1_31 that was good and a developer checks in a bad
set of changes and tags with DEV_1_32, then you IIRC can issue
cvs update -jDEV_1_32 -jDEV_1_31
to just back out the changes that where faulty assuming later changes did not
logically depend on those.
of course you may want/need to then commit the current sandbox set so later
changes don't build on the broken code.
Thanks
S.
--
Todd Denniston
Crane Division, Naval Surface Warfare Center (NSWC Crane)
Harnessing the Power of Technology for the Warfighter
Even when this disclaimer is not here,
the opinions expressed by me are not necessarily sanctioned by and
do not necessarily represent those of my employer.
Also even when this disclaimer is not here, I DO NOT have authority to
direct you in any way to alter your contractual obligation
and my email can NOT be used as direction to modify a contract.