[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: protorev file handling in svn_fs_commit_txn

From: Daniel Shahaf <d.s_at_daniel.shahaf.name>
Date: Tue, 26 Nov 2013 14:05:10 +0200

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

This is an archived mail posted to the Subversion Dev mailing list.