protorev file handling in svn_fs_commit_txn

Suppose svn_fs_commit_txn fails to complete, either due to a transient
error like disk full or file permissions, or because the process is
killed. Further suppose that the transaction remains on disk. Is it
valid to call svn_fs_commit_txn again on the same transaction? There
doesn't seem to be anything to prohibit it but the FSFS implementation
can lead to revision files that are not correct.

Each transaction has a protorev file containing the file representations
built up during the transaction. When svn_fs_commit_txn is called the
protorev file is expected to contain just the sequence of file reps.
The commit code appends the node reps, change lists, etc. to the
protorev file and then moves it to create the new revision file. What
happens when svn_fs_commit_txn is interrupted and retried depends on
when the interrupt occurs. An interrupt after appending but before
moving will leave the appended data in the protorev file, and then a
retry will add the appended data a second time. The result is a
revision file that contains duplicate nodes, multiple change lists, etc.
The problem is likely even worse if changes are made to the transaction
between the calls to svn_fs_commit_txn.

So, is it valid to retry svn_fs_commit_txn? Is it valid to modify the
transaction after svn_fs_commit_txn fails? If it is valid we should
probably try to make the result independent of the number of attempts.
If it is not valid we should probably try to make the attempts fail.

This is mostly a theoretical problem at present: servers and clients
tend to delete transactions when svn_fs_commit_txn fail and so no retry
is possible.

In the long term perhaps we should dispense with the protorev file. We
could stored file reps in individual files in the transaction directory
and build the revision file from scratch. There would be an IO penalty,
writing the file reps twice, but we might gain the ability to write
file reps into the transaction in parallel.

-- 
Philip Martin | Subversion Committer
WANdisco // *Non-Stop Data*