Excerpts from mail: Mon, 2 Nov 92 14:37:16 -0500
From: Lynne Cohen Duncan <[EMAIL PROTECTED]>
To: [EMAIL PROTECTED]
Subject: User acceptance of AFS
> The users have the following complaints. Perhaps you have encountered
> simple answers/solutions to them. Please let me know how you handled
> any of these:
>
> RCS locking (Our researchers use co -l to prevent overlapping
> updates of project files. This doesn't work under AFS
> because of directory-wide permissions.)
This can be an annoyance preventing the use of a shared workspace for RCS
files; but there is a reasonable work-around. Under AFS, RCS can still
lock a checked out file to prevent another checkout but can't by itself
write-protect the checked-out file in an AFS directory. The RCS user
wanting to truely lock the checked out file can
* create a private workspace in an AFS directory
* set the acl on the directory to prevent intrusion
* create symbolic links from the private workspace to
the RCS directory (or ,v files)
* create symbolic links from the private workspace to any read-only
files associated with the current task
* break the link to any file to be checked out (this is important)
* co -l to make a checked out copy of the file in the private workspace
In some ways, this model of sharing RCS files is actually preferable to
using a shared directory because users don't have to trip over someone elses
temporary or special files that always seem to pile up in public places.
Sandy Orlow (Systex, Inc.) phone: (301) 402-1533
Building 12A, Room 2013 uucp: uunet!sandy%alw.nih.gov
National Institutes of Health Internet: [EMAIL PROTECTED]
Bethesda, MD 20892 FAX: (301) 402-2867
