[web-team] modified/unlocked RCS files

[Rick Moen]

Quoting Mark Weisler (mark at weisler-saratoga-ca.us):

> Hi all,
> I noticed a minor typo on the aforementioned page.  I went in to
> change buy to "busy" and was informed that a "writeable" (I think that
> was the term I saw) instance of the file existed. I took it to mean,
> "You don't have to check the file out as it is already writable."
> 
> I made the change but now see the system is kvetching. So, NP, I'll go
> in and check it out, make the change, then put it back.

Don't feel bad.  Both RCS and the cvswatcher cronjob/script are a bit
stupid, that way.  

The main thing to remember about RCS is that it relies on a primitive
form of "locking" using file permissions.  To explain:  RCS predated 
development of real VCSes capable of merging / resolving conflicts. 
So, instead, you "checked out" a file, and RCS chmod'ded it to make it
writeable.  When you later "checked in" that same file as revised, 
RCS chmod'ded the stored version once again, making it read-only.  Thus,
RCS's primary means of determining whether a file is checked out or not
is to look at its rights mask.

Now, you might be thinking:  "Having production files be set normally
read-only sounds problematic, and something of an accident waiting to
happen", and you'd be right.  

I've had the same thing happen to me as happened to you, repeatedly:
I'd ask to check out a file, and RCS would say "Hmm, that file is
already writeable.  Maybe someone else is already working on it.  Are
you sure you want to do that?" (or words to that effect).  Why was the
file writeable?  Dunno, but that could certainly occur any number of
ways.  

I believe the best way to proceed, in such a situation, is:

1.  Well, maybe someone really _is_ working on the file.  You don't
    want to ignore the "lock" if that's really the case.  If it is,
    that person's going to have the file checked back in within the
    next day, or he/she will get nagged by cvswatcher.  ;->  
2.  But probably it's just another rights mask screwup.  If you're 
    guessing it is, then, me, just to be cautious, I tend to cp
    the stored version somewhere -- /tmp, my home directory, somewhere 
    -- just in case I'm screwing up, for safekeeping.
3.  _Then_, I do "co -l [filename].  This operation results in the 
    stored file getting overwritten by the most recent checked-in
    data inside the .RCS subdirectory, and makes the stored file
    writeable (i.e., you've checked it out).
4.  Now, just to make sure you were _not_ screwing up, diff the 
    stored version (the one you just checked out) against the 
    snapshot you made a minute ago.  Does the snapshot have revisions
    that the stored one doesn't?  If so, oops.  Fortunately, you can 
    cp the snapshot over (where the revisions are still preserved),
    overwriting the stored version, and do "ci -u [filename]", so that
    that other person's revisions get checked in and not lost.
5.  _Now_ you can do "co -l [filename]" again, and you're in good
    shape.

The cvswatcher script, if I recall/guess correctly, merely peeks at the 
time stamps in RCS metadata, to determine how many hours any checked out
files have been writeable.  If cvswatcher thinks it's been 12+ hours or
so (or whatever it is), it sends you a reminder, then after so-and-so
additional hours, sends notes to web-team.

So, to make it happy, check out the file in question (first making a
copy to protect against losing work in progress), diff to make sure
nothing is getting lost, then check it back in.

Sorry it put you through that.  Welcome to the club!  ;->