I can say from experience that assembling a sandbox from an unlocked
repository is no more or less safe than any out-of-date sandbox, provided
the CVS metadata are correct with respect to the contents of the working
files. In either case, a "cvs update" is required (with the accompanying
conflicts resolved) before a commit can be completed. This can be tricky
if the read operation is done concurrently with a commit or tag operation.
The first point, that the operation be read-only is absolutely correct.
To resolve issues surrounding concurrent reads and writes, my method
required that all revisions retrieved from the repository be identified
in advance.
>--- Forwarded mail from [EMAIL PROTECTED]
>On Fri, Mar 23, 2001 at 11:24:19PM +0100, Assar Westerlund wrote:
>> What the patch below does is introduce an
>> option (`-R') for running without creating any lock-files.
>This would let any user subvert CVS locking in the interest of
>"saving time" (famous last words) and potentially corrupt the
>repository.
>-R would be safe if:
> - it could be used *only* on operations that don't change the
> repository (eg. checkout), and
> - it arranged that the user not be allowed to commit from the
> resulting sandbox
>Failing that, it should be an optional feature chosen at
>configure time -- and should be disabled by default!
>--- End of forwarded message from [EMAIL PROTECTED]
_______________________________________________
Info-cvs mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/info-cvs
