Philip Martin wrote on Tue, Nov 26, 2013 at 11:53:05 +0000: > 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. >
Assuming there are no changes to the transaction, is there a correctness problem resulting? Or is the problem simply one of wasted space, i.e., the resulting revision file would contain N copies of the change list but only one copy would be pointed to? > 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. Hmm. I wonder if we could just create a, say, 1MB file full of zeroes, and than allocate a quarter MB to each of four threads? And write to all quarters in parallel?
