Stefan Sperling wrote on Thu, Mar 28, 2013 at 12:49:46 +0100: > On Thu, Mar 28, 2013 at 11:36:50AM -0000, danie...@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?
