> -----Original Message-----
> From: MARTIN PHILIP [mailto:codematters_at_ntlworld.com] On Behalf Of
> Philip Martin
> Sent: dinsdag 31 juli 2012 21:30
> To: Julian Foad
> Cc: dev_at_subversion.apache.org
> Subject: Re: FSFS verifies rep-cache when disabled
>
> Julian Foad <julianfoad_at_btopenworld.com> writes:
>
> > Philip Martin wrote:
> >
> >>& quot;svnadmin verify" verifies a rep-cache.db file even when
> >> rep-caching is disabled. This appears to be intentional but I don't
> >> understand the reasoning.
> >>
> >> svn_fs_fs__verify calls svn_fs_fs__exists_rep_cache to see if the
> >> cache exists and then calls svn_fs_fs__walk_rep_reference which has
> >> the comment:
> >>
> >> /* Don't check ffd->rep_sharing_allowed. */
> >> SVN_ERR_ASSERT(ffd->format >=
> SVN_FS_FS__MIN_REP_SHARING_FORMAT);
> >>
> >> Why should verify attempt to verify a cache that is disabled?
> >
> >
> > I have a vague recollection that we argued at the time, that if and
> > when the admin twiddles the knob to enable it, then it will be used
> > without any further checking (or emptying) of it at that time, so it
> > is part of the repository state that needs to be correct for the
> > repository (including its knobs) to be considered 'verified good'.
> > And that still makes sense to me.
If it isn't enabled at all the performance cost of verifying is almost nil (but we shouldn't create the DB if it doesn't exist).
If there is data inside then the admin tiddled the knob and I think we should verify it (whether or not it is enabled for new revisions).
> I still find it a bit odd: I'd expect enable-rep-sharing in fsfs.conf to
> control all processing of rep-caching. What about recover and upgrade?
> Should they also ignore that flag? If so then my r1367674 change to
> recover is wrong.
Not sure about those.
Bert
>
> --
> Certified & Supported Apache Subversion Downloads:
> http://www.wandisco.com/subversion/download
Received on 2012-07-31 22:12:11 CEST