Stefan Sperling wrote on Thu, Mar 28, 2013 at 12:49:46 +0100:
> On Thu, Mar 28, 2013 at 11:36:50AM -0000, danielsh_at_apache.org wrote:
> > Author: danielsh
> > Date: Thu Mar 28 11:36:50 2013
> > New Revision: 1462054
> >
> > URL: http://svn.apache.org/r1462054
> > Log:
> > On the verify-at-commit branch, add a backend-independent implementation:
> > a db/fs.conf file.
>
> As I said on IRC, I think it makes more sense to implement this
> on a per-filesystem basis. The generic fs wrapper can only verify
> the transaction, but there is no guarantee that this really represents
> the data written during commit. E.g. in FSFS we could check the rev
> and revprop files before updating 'current', which leaves less room
> for error between verification and commit. For BDB -- dunno.
>
In BDB a transaction is promoted to a revision by amending the
'revisions' table. If BDB supports nested transactions (like sqlite
does), it should be possible to: start a transaction, modify
'revisions', call svn_fs_base__verify_root() (which doesn't exist yet),
abort the transaction.
Or alternatively we could introduce an error code for "This backend
doesn't support svn_fs_verify_root() on transactions" and trap it in
svn_fs_commit_txn().
> If we decide that verifying transactions before commit is a good
> thing, I'd much rather see a new 'svnlook verify' command that can
> be run from the pre-commit hook, instead of this implementation.
>
This makes sense. How would such a subcommand relate to 'svnadmin verify'?
> Does that make sense?
Received on 2013-03-28 13:01:33 CET