On Tue, Apr 23, 2013 at 6:54 PM, Philip Martin
<philip.martin_at_wandisco.com>wrote:
> stefan2_at_apache.org writes:
>
> > Author: stefan2
> > Date: Mon Apr 22 22:26:39 2013
> > New Revision: 1470738
> >
> > URL: http://svn.apache.org/r1470738
> > Log:
> > Make svn_fs_verify accept a FS_CONFIG parameter similar to svn_fs_open()
> > and svn_fs_create(). Use that in svn_repos_verify_fs2 to check FS with
> > the same configuration parameters that were used open opening FS.
> >
> > Besides the mere symmetry aspect, this is essential use consistent cache
> > settings during FS verification, particularly using the same, separate
> > cache namespace.
>
> > @@ -2466,7 +2480,9 @@ svn_fs_pack(const char *db_path,
> > /**
> > * Perform backend-specific data consistency and correctness validations
> > * to the Subversion filesystem (mainly the meta-data) located in the
> > - * directory @a path. Use @a scratch_pool for temporary allocations.
> > + * directory @a path. Use the backend-specific configuration @a
> fs_config
> > + * when opening the filesystem. @a NULL is valid for all backends.
>
> I assume the NULL comment refers to fs_config?
Correct.
> At the start of the log
> you say it is essential to use consistent configs. Does using NULL
> result in consistent configs?
>
Consistent as in "same as in all other API calls potentially opening a FS".
You can pass NULL consistently to all of them (in which case the defaults
apply).
svn_repos_verify_fs2 accepts an already open FS and will now pass the
same config to svn_fs_verify - whether NULL or not. It has been forced to
use the defaults in the past, which could be inconsistent with the ones used
by original FS instance.
-- Stefan^2.
--
*Join one of our free daily demo sessions on* *Scaling Subversion for the
Enterprise <http://www.wandisco.com/training/webinars>*
*
*
Received on 2013-04-23 19:33:32 CEST