On Tue, Aug 19, 2014 at 5:17 PM, Bert Huijben <bert_at_qqmail.nl> wrote:
>
>
> > -----Original Message-----
> > From: stefan2_at_apache.org [mailto:stefan2_at_apache.org]
> > Sent: dinsdag 19 augustus 2014 16:59
> > To: commits_at_subversion.apache.org
> > Subject: svn commit: r1618880 - in
> /subversion/trunk/notes/api-errata/1.9: ./
> > fs001.txt
> >
> > Author: stefan2
> > Date: Tue Aug 19 14:58:37 2014
> > New Revision: 1618880
> >
> > URL: http://svn.apache.org/r1618880
> > Log:
> > Add an erratum for svn_fs_props_changed and svn_fs_contents_changed.
> >
> > * notes/api-errata/1.9
> > (): New folder. It's the first erratum for 1.9.
> >
> > * notes/api-errata/1.9/fs001.txt
> > (): New file.
> >
> > Added:
> > subversion/trunk/notes/api-errata/1.9/
> > subversion/trunk/notes/api-errata/1.9/fs001.txt
> >
> > Added: subversion/trunk/notes/api-errata/1.9/fs001.txt
> > URL: http://svn.apache.org/viewvc/subversion/trunk/notes/api-
> > errata/1.9/fs001.txt?rev=1618880&view=auto
> > ==========================================================
> > ====================
> > --- subversion/trunk/notes/api-errata/1.9/fs001.txt (added)
> > +++ subversion/trunk/notes/api-errata/1.9/fs001.txt Tue Aug 19 14:58:37
> > 2014
> > @@ -0,0 +1,41 @@
> > +API ERRATUM -- $Id$
> > +
> > +Root Cause of Errata: implementation/docstring mismatch
> > + Library(s) Affected: libsvn_fs_fs, libsvn_fs_base
> > +Function(s) Affected: svn_fs_props_changed, svn_fs_contents_changed
> > + New Behavior in: 1.9
> > + Related Issues: n/a
> > +
> > +
> > +== Details ==
> > +
> > +The docstrings for svn_fs_props_changed and svn_fs_contents_changed
> > +did not state that these functions would only perform backend (BDB,
> > +FSFS) specific quick checks. Moreover, the implementation of
> > +svn_fs_props_changed would not only generate false positives as
> > +svn_contents_changed did -- which could later be identified by the
> > +caller -- but also false negatives.
> > +
> > +This behavior makes these APIs very hard to use inefficiently and
> > +creates dependencies between implementation details and API users.
>
> ^^^
> 'Hard to use inefficiently'... so it was a well-defined efficient API?
>
Oops .. lol. Fixed in r1618895.
-- Stefan^2.
Received on 2014-08-19 18:42:58 CEST