[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: svn commit: r1103771 - in /subversion/trunk/subversion: libsvn_client/prop_commands.c svn/propedit-cmd.c svn/propget-cmd.c

From: Hyrum K Wright <hyrum_at_hyrumwright.org>
Date: Tue, 17 May 2011 07:21:43 +0000

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.

Received on 2011-05-17 09:22:20 CEST

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.