Re: svn commit: rev 3977 - in trunk/subversion: include libsvn_wc libsvn_client

kfogel@tigris.org writes:

> + return svn_error_createf
> + (SVN_ERR_UNSUPPORTED_FEATURE, 0, NULL,
> + "Recursing on previous revision not yet supported.\n"
> + "(http://subversion.tigris.org/issues/show_bug.cgi?id=943)\n",
> + target);

../svn/subversion/libsvn_client/prop_commands.c: In function `svn_client_propget':
../svn/subversion/libsvn_client/prop_commands.c:508: warning: too many arguments for format
../svn/subversion/libsvn_client/prop_commands.c: In function `svn_client_proplist':
../svn/subversion/libsvn_client/prop_commands.c:918: warning: too many arguments for format

> +
> + /* In the recursive case, the correctest behavior is
> + hard to implement. If the command is
> +
> + svn propget -rPREV -R SOMEDIR
> +
> + then the PREV keyword will expand to the previous
> + revision for SOMEDIR, and then *that same*
> + revision will be used all the way down the
> + recursion, even though there might be objects
> + beneath SOMEDIR that have different previous
> + revisions. For now, we punt and don't handle
> + 'svn propget -R -rPREV' at all. I suspect it's
> + an edge case anyway, and I'm not sure that my
> + idea of the "correct" interpretation of PREV
> + will be the user's idea anyway. */

'svn diff -rPREV SOMEDIR' uses the previous revision of SOMEDIR all
the way down the recursion, so this behaviour is already visible to
the user.

-- 
Philip Martin
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org