On Tue, Apr 23, 2013 at 6:54 PM, Philip Martin <philip.mar...@wandisco.com>wrote:
> stef...@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>* * *
