[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: Johan Corveleyn <jcorvel_at_gmail.com>
Date: Tue, 17 May 2011 11:34:03 +0200

On Tue, May 17, 2011 at 11:49 AM, Daniel Shahaf <d.s_at_daniel.shahaf.name> wrote:
> Hyrum K Wright wrote on Tue, May 17, 2011 at 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.
>>
>
> Two things:
>
> * Could we have written the cmdline client in 1.6 in a way that's
>  oblivious of the absoluteness/relativeness of the hash keys?
>
> * Concretely: the svn_client_propget3() docstring states that
>  the keys will be prefixed by @a TARGET.  That seems to me to
>  imply svn_dirent_join(TARGET, ...) --- without changing whether
>  TARGET is absolute or relative.

Yes. I don't have a strong opinion in this discussion, but completely
objectively, one could also say that the documentation was flawed (or
inaccurate), i.e. a bug in the docstring. It talked about a PATH, but
every consumer deduced it had to be a relative path ...

-- 
Johan
Received on 2011-05-17 11:34:55 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.