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?
Received on 2013-11-26 13:06:01 CET