Re: [Slashcode-general] Still strange behavor in one site

[Shane <sh...@lo...>]

On Dec 20, 2004, at 9:24 AM, Gaulin, Mark wrote:

>> One more thing... we don't recommend using "latest CVS."  At any
>> given moment, what's in CVS may be broken.  Each week or so, we
>> nail down a build that looks good, and give it a T_ or R_ tag.
>> That's our process.  So the furthest that almost all sites
>> should go toward the bleeding edge is the most recent T_ or R_
>> tag.  If you just do a "cvs update -A", what you get may not
>> even pass "make".  OK, you've been warned :)
>> --
>>  Jamie McCarthy
>
>
> Are the R_ and T_ tags listed somewhere in CVS or elsewhere on 
> sourceforge?  Do you guys post a message somewhere when new T_ or R_'s 
> come out?
>
> I've been looking for a way to find a list of them with dates (and 
> hopefully a little comment or two), but the best I've come up with so 
> far is to poke around in CVS at files that are likely to change (like 
> "sql/upgrades") and try to infer the date of each label and some of 
> the changes in that version from that.

Here's what I normally do:

#cd /usr/local/src/slash/slash
cvs -n update -dP > /tmp/changes.txt

then go through that text file. If needed I'll use slashcode's cvsweb 
to browse through changes in an easier-to-read-fashion.

I normally also cvs diff sql/mysql/upgrades

after I've done an upgrade to our server, I edit sql/mysq/upgrades and 
append a

"lottadot updated yyyy-mm-dd"

to it (similar to what they do for slashdot).

Then even when I do a final update -dP before I begin upgrading, I 
always know the last place in the upgrades file that our production 
systems are running at.

I tend not to use the T_ or R_ tags. But I also keep up with daily 
reading of the bug reports in slash's sfproject page. So between those, 
and hanging around on irc, I generally know what's going on with the 
code, and what problems, if any people are having.

If problem reports are down, and there's a reason to upgrade to latest 
cvs, I'll update the c/o, apply my patches, install it on a 
test-machine (generally my laptop), install a test-site, try it out, 
and if it looks good then upgrade the production server.

  Shane