On Tue, Aug 19, 2014 at 5:17 PM, Bert Huijben <b...@qqmail.nl> wrote:
> > > > -----Original Message----- > > From: stef...@apache.org [mailto:stef...@apache.org] > > Sent: dinsdag 19 augustus 2014 16:59 > > To: comm...@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.
