From: "Steven Lembark" <[EMAIL PROTECTED]>
> One quick way to deal with testing things is to tag the releases
> with something meaningful and pass the tag to Q/A. They do an
> update -d -P -r yourtag and test it. If things work then the update
> gets run again in production and life goes on. Since nothing but
> tagged releases go into production they can also back off easily if
> a problem is found; ditto Q/A.
Yes, you always need to tag everything at least at the 'known-working'
points. In addition to assigning unique tags that you have to remember,
you can 'float' existing tags to specific points which makes it easier
to script actions and keep track of the 'release-1' and 'release-2' versions.
For example, one script can pull several developers' work together from
the head of the repository into a test area. Then when it all works, another
script can float the 'release-n' tags up one position, tag the testbed instance
as the current release, then update using the release tag to the production
machine or a staging area where you rsync to production. This allows new
work to continue at the head of the repository without getting pulled into
a production update before testing and gives you a known tag to go back
to the previous tested/working system. I've never actually backed out a
whole release that way but its one of those things that gives a warm-fuzzy
feeling knowing that you can and the ability to see all the changes between
versions from cvsweb has made it much easier to find and fix problems
that pop up after an update into production.
---
Les Mikesell
[EMAIL PROTECTED]
