On 07/22/2010 05:56 PM, Paul Burba wrote:
> On Thu, Jul 22, 2010 at 5:04 PM, Bert Huijben <bert_at_qqmail.nl> wrote:
>> Shouldn't this be fixed in the ra layer implementations then?
>
> From what Mike told me in
> http://subversion.tigris.org/issues/show_bug.cgi?id=3657#desc9 I
> didn't think so. I assumed that some users of the svn_delta_editor_t
> rely on this behavior, since we are quite purposeful about it...but
> looking again at the docstring for change_file_prop, it seems clear
> that if anybody is relying on this behavior, they are wrong:
>
> /** Change the value of a file's property.
> * - @a file_baton specifies the file whose property should change.
> * - @a name is the name of the property to change.
> * - @a value is the new (final) value of the property, or @c NULL if the
> * property should be removed altogether.
> *
> * The callback is guaranteed to be called exactly once for each property
> * whose value differs between the start and the end of the edit.
> *
> * All allocations should be performed in @a pool.
> */
> svn_error_t *(*change_file_prop)(void *file_baton,
> const char *name,
> const svn_string_t *value,
> apr_pool_t *pool);
>
> I'll revisit this tomorrow.
Thanks to wonders of English grammar, the promise above can be restated like so:
For each property whose value differs between the start and the end
of the edit, invoke the callback exactly once per property. But
for each property whose value does NOT differ between the start and
the end of the edit, you can call this sucker all day long in any way
you want!
So, it's *technically* fine for an editor driver to slam unchanged
properties through the interface. :-)
(But no, I highly doubt that was the original intent of the promise.)
--
C. Michael Pilato <cmpilato_at_collab.net>
CollabNet <> www.collab.net <> Distributed Development On Demand
Received on 2010-07-23 20:31:32 CEST