Re: Rename atomicity

[Paul Sander]

Have you looked into the way that RCS works?  It does not replace the
RCS files in-place; it makes a modified copy in its lock file, and then
renames the lock file on top of the original.

Due to the way that the filesystem works, if the original is open for
reading at the time of the rename, it remains open with the old data,
and gets removed when it's closed.  So the sandbox gets the correct
data.

The only concern is about getting the proper version of the file, due
to the race condition between the open (for read) and the rename.  This
is why you must identify the proper version explicitly before the open.

I've used this method with great success for years, with concurrent
commits, under the conditions you state.  There have been no corruptions
of any sandbox to date.

--- Forwarded mail from address@hidden

Paul Sander wrote:

> 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.

What of the case where a file is being written while a read-only CVS attempts
to read it.  Providing RCS doesn't consistently break, and I'm far from sure
it will, the resulting partial file in the sandbox will have valid metadata.
If the file was touched in the sandbox, a later commit could check in
garbage.

--- End of forwarded message from address@hidden