On Tue, May 17, 2011 at 7:51 AM, Daniel Shahaf <d.s_at_daniel.shahaf.name> wrote:
> hwright_at_apache.org wrote on Mon, May 16, 2011 at 15:36:24 -0000:
>> Author: hwright
>> Date: Mon May 16 15:36:24 2011
>> New Revision: 1103771
>>
>> URL: http://svn.apache.org/viewvc?rev=1103771&view=rev
>> Log:
>> Convert a bit of the recursive propget to use absolute paths, by doing path
>> relativifcation in the command line program, where it belongs.
>>
>> Note: I *think* this is backwards compatible, since we promise paths, but
>> don't specify absolute or relative in the docs. If somebody has an alternative
>> interpretation, we can do the API-rev dance.
>>
>> * subversion/svn/propget-cmd.c
>> (print_properties): Make a relative path from an absolute one, if possible.
>>
>> * subversion/svn/propedit-cmd.c
>> (svn_cl__propedit): Fetch the property from the hash via absolute path.
>
> How can it be a backwards compatible API change if you had to change the
> API consumer (the cmdline client)?
If the consumer depends upon an (undocumented) implementation detail,
you can bet it'll need to change when those details change. (Example:
anybody relying upon the entries-file implementation detail is going
to have a hard time with 1.7.)
I maintain that if we didn't document the behavior, existing clients
are depending on an implementation detail (which they shouldn't be
doing). This doesn't mean we can't rev the API to make things easier
for them, but it does mean we are well within our rights to change the
implementation and have things break for the consumer.
-Hyrum
Received on 2011-05-17 09:22:20 CEST