Re: svn commit: r991642 - /subversion/trunk/subversion/libsvn_wc/wc_db.c

[Greg Stein <gs...@gmail.com>]

On Wed, Sep 1, 2010 at 14:34,  <rh...@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 ?

Cheers,
-g

RE: svn commit: r991642 - /subversion/trunk/subversion/libsvn_wc/wc_db.c

[Bert Huijben <be...@qqmail.nl>]

> -----Original Message-----
> From: Greg Stein [mailto:gstein@gmail.com]
> Sent: donderdag 2 september 2010 2:05
> To: dev@subversion.apache.org
> Subject: Re: svn commit: r991642 -
> /subversion/trunk/subversion/libsvn_wc/wc_db.c
> 
> On Wed, Sep 1, 2010 at 14:34,  <rh...@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