As I understand it, our working copy log discipline is:
1. Create a temporary logfile.
2. Write out a consistent set of operations to the file.
3. Move the temporary file into place as a real logfile.
4. Execute the operations.
5. Remove the logfile.
To be resistant against system crashes, I believe we need to be using
fsync() or the Windows equivalent at step 2 and possibly during step
4. The particular failure cases depend on the exact filesystem being
used, but essentially, there is no guarantee in most filesystems that
step 2 will be committed to disk before step 3 is, unless you fsync()
the file before closing it. Similarly, if step 4 involves writing
data to files, there is no guarantee that those writes are committed
to disk before step 5 is committed.
I wouldn't look here for any real problems people have experienced so
far. System crashes are rare, at least on Unix, and most of the time
the worst that happens is the new file showing up with zero length
(but there's no guarantee of that). A zero-length logfile will of
course do no damage, though a zero-length file elsewhere in .svn
might.
I think we would have to extend APR to be able to call fsync() on Unix
and the equivalent call on Windows.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Thu Aug 8 22:36:03 2002