Mailing-List: contact commits-help@subversion.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@subversion.apache.org
Received-SPF: pass (athena.apache.org: local policy)
Date: Tue, 17 May 2011 11:49:29 +0200
From: Daniel Shahaf <d.s@daniel.shahaf.name>
To: Hyrum K Wright <hyrum@hyrumwright.org>
Cc: dev@subversion.apache.org, commits@subversion.apache.org
Subject: Re: svn commit: r1103771 - in /subversion/trunk/subversion:
	libsvn_client/prop_commands.c svn/propedit-cmd.c svn/propget-cmd.c
Message-ID: <20110517094929.GB31904@lp-shahaf.local>
References: <20110516153624.704BE23888EA@eris.apache.org>
 <20110517075052.GA30040@lp-shahaf.local>
 <BANLkTi=vx2Rpc0je57gEnGrv-tsJpvshKQ@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <BANLkTi=vx2Rpc0je57gEnGrv-tsJpvshKQ@mail.gmail.com>
User-Agent: Mutt/1.5.18 (2008-05-17)

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