[web-team] modified/unlocked RCS files

[Mark Weisler]

On Wednesday 21 May 2008 12:10:39 Rick Moen wrote:
> 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,ebianhelp.co.uk/backuptools1.htm
> 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!  ;->
>
>
> _______________________________________________
> web-team mailing list
> web-team at lists.svlug.org
> http://lists.svlug.org/lists/listinfo/web-team
Rick and Tim,

Thanks for helping on this. I duly note that [web-team] mail is available via 
archive so I'll likely be referring to your messages and knowledge again-and 
I know where to find the material.
Mark


-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part.
Url : http://lists.svlug.org/archives/web-team/attachments/20080521/7aa10267/attachment-0001.bin