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

> -----Original Message-----
> From: hwright_at_apache.org [mailto:hwright_at_apache.org]
> Sent: maandag 16 mei 2011 17:36
> To: commits_at_subversion.apache.org
> Subject: svn commit: r1103771 - in /subversion/trunk/subversion:
> libsvn_client/prop_commands.c svn/propedit-cmd.c svn/propget-cmd.c
>
> 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.

I really think that we should do the 'API-rev dance' here, sorry.

Before this patch you could call this function, to get the properties for a path 'path', and then do an apr_hash_get(result, "path", APR_HASH_KEY_STRING) and you would get the property for your path.

After this patch you get NULL, because you receive a hashtable with as key for the file like "/some/long/longer/path".
(Same problem would apply to the language bindins)

I think this is going to break *a lot* of clients that use our api or that pass relative "../style" paths to svn.
svn_client_propget3 is one of the most popular Subversion apis used by third party applications. (It's hard to handle raw properties using invocations of 'svn', so it convinces users to switch to the api)

We should probably do the full conversion for a deprecation wrapper instead of only 'similar' relative paths, by joining the originally passed anchor back to the relative paths of the results.

        Bert
Received on 2011-05-16 18:19:20 CEST