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

Re: svn commit: r1462054 - in /subversion/branches/verify-at-commit/subversion: include/svn_fs.h libsvn_fs/fs-loader.c libsvn_fs/fs-loader.h

From: Daniel Shahaf <d.s_at_daniel.shahaf.name>
Date: Thu, 28 Mar 2013 14:00:54 +0200

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

> 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

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

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.