> -----Original Message-----
> From: Greg Stein [mailto:gstein_at_gmail.com]
> Sent: donderdag 2 september 2010 2:05
> To: dev_at_subversion.apache.org
> Subject: Re: svn commit: r991642 -
> /subversion/trunk/subversion/libsvn_wc/wc_db.c
>
> On Wed, Sep 1, 2010 at 14:34, <rhuijben_at_apache.org> wrote:
> > Author: rhuijben
> > Date: Wed Sep 1 18:34:26 2010
> > New Revision: 991642
> >
> > URL: http://svn.apache.org/viewvc?rev=991642&view=rev
> > Log:
> > Fix some compatibility with the old entries world that was broken by
> using
> > the SINGLE_DB define in wc_db.c. After this patch the generic
> flush_entries
> > code is extended to automatically flush the parent stub entry (if
> that
> > exists) if a directory is modified.
>
> How did you find this one? Is there a test that exposes it? Or one
> that will ensure it won't happen again? ie. something in
> tests/libsvn_wc/entries-compat.c ?
This was a simple matter of code review. Almost every #ifdef SINGLE_DB in
the first few db ops in wc_db.c contained a flush_entries() call.
And as we never use the entries read or cache code in our code base, there
is no way that we can really test this. (We can add a few tests in the
entries tests, but this will never cover all the possible current and future
database operations).
In the past you suggested: When in doubt, flush the entries cached in the
access batons. And enabling SINGLE_DB broke that pattern for these
functions.
In all the cases I knew, this revision moved the flushing outside the #ifdef
SINGLE_DB blocks. (There might be more wc_db operations that need additional
flushing, but a simple scan of all the db operation didn't show any of
these. But an extra pair of eyes on this would certainly help)
Bert
Received on 2010-09-02 10:49:35 CEST