subversion-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Daniel Shahaf <...@daniel.shahaf.name>
Subject Re: svn commit: r1103771 - in /subversion/trunk/subversion: libsvn_client/prop_commands.c svn/propedit-cmd.c svn/propget-cmd.c
Date Tue, 17 May 2011 09:49:29 GMT
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@daniel.shahaf.name> wrote:
> > hwright@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.

> -Hyrum

Mime
View raw message