OS/2 Shareware BBS: 14 Text/14-Text.zip/srcsafe.zip/QA_RO.ZIP/QA_RO.TXT

Text File | 1993-11-15 | 4KB | 79 lines

SourceSafe Q & A: Read-Only Files

** SourceSafe Question **

Some of the files in my local directory have been tagged so that the operating
system will not let me change or delete them.  When and why does SourceSafe do
this?

** The Basic Answer **

SourceSafe works, in general, by the following rules.

1. If you have a file checked out, your local copy is writable (ie the file can
be modified).

2. If you do not have a file checked out, your local copy is not writable
(cannot be modified).

The exact method of making a file "not writable" varies with the operating
system: a DOS file is made read-only, a Macintosh file is locked, and a UNIX
file has write permission turned off for all users.  But the basic idea is
always the same: when you do not have a file checked out, SourceSafe tags the
file unmodifiable.  Hence, SourceSafe commands such as Add, Update, Uncheckout,
and Get leave your file read-only; Checkout makes it writable.

** Why SourceSafe Makes Files Read-Only **

The first important point to understand here is that making files read-only is
not for security purposes.  SourceSafe is not trying to prevent you forcefully
from modifying the file.  If you Get a file, and then manually make it writable
and start making changes, you have not endangered SourceSafe's Checkout system.
 (Remember, the true "master" copy of every file is in SourceSafe; and
SourceSafe will not let you Update a file that you do not personally have
checked out, regardless of its read-only status!)

That being said, there are two principal reasons SourceSafe locks your local
copy of a file.

1. The read-only attribute serves as a reminder to the user that the file is
not checked out.  Most editors will alert you when you try to modify a read-
only file, thus reminding you to Checkout the file before modifying it.  This
can save you the great agony of spending hours modifying a file, only to
discover that you forgot to check it out!

2. The read-only attribute serves as a signal to SourceSafe of whether you have
been modifying a file.  When a file is read-only, SourceSafe assumes that the
file is safely in SourceSafe; hence, when you attempt to Get the file,
SourceSafe will cheerfully overwrite your local copy.  But a writable file may
be one you have checked out, or which you have set writable and modified, and
may therefore contain information which exists nowhere else; by default,
SourceSafe will never overwrite such a file.

** Changing SourceSafe's Use of Read-Only Files **

The behavior described above is SourceSafe's default behavior; however, like
most assumptions made by SourceSafe, this can be changed if your needs are
different.  There are two ways to modify SourceSafe's use of read-only files.

The first is through the SS.INI variable Use_Readonly.  If the following line
is placed in your SS.INI file, SourceSafe will never tag files read-only.

Use_Readonly = No

This line signals SourceSafe never to make a file read-only, and not to use the
read-only attribute as its signal that a file should not be overwritten.
(SourceSafe will use the file's actual Checkout status in this case.)  As with
all INI variables, this can be set per-user in SS.INI or globally in
SYSTEM.INI; and it can be set project-by-project or generally.  See the
description of SS.INI in the SourceSafe User's Manual or On-Line Help for more
details.

The other option, available from the SourceSafe command-line only, is to change
SourceSafe's use of the read-only flag for an individual command.  This is done
via the -W (writable) parameter.  If you use the -W with a command such as Get,
Add, or Update, which would normally tag a file read-only, the file will be
made writable.  If you have Use_Readonly set to No by default, you can use the -
W- parameter to override it for an individual command and make the file read-
only.