On Mon, 08 May 2006, C. Michael Pilato wrote:
> Julian Foad wrote:
> > Either of: implement blame of the working version (+1), or reject it
> > with an error (+0).
> +1 on immediately, today, returning an SVN_ERR_UNSUPPORTED_FEATURE for blame
> of 'WORKING'.
Here's a patch for discussion. (I've haven't been able to test this
yet, as one can only pass WORKING via the API, which there's currently
insufficient scaffolding for in the C test framework. Might be able
to hack the svn client to do this test.)
I'd like to see something similar backported to 1.4.x.
Rather than silently converting a 'blame' of the WORKING revision to
that of BASE, return an error explicitly stating that 'blame' of
WORKING is unsupported.
In the future, 'blame' my grow support for this.
(svn_client_blame3): Update doc string to reflect the new behavior.
(svn_client_blame3): Return SVN_ERR_UNSUPPORTED_FEATURE for attempts
to call 'blame' on the WORKING revision.
Found by: Stefan Küng <firstname.lastname@example.org>
Suggested by: julianfoad, cmpilato
--- subversion/include/svn_client.h (revision 19556)
+++ subversion/include/svn_client.h (working copy)
@@ -1287,9 +1287,11 @@
* WC targets.
* If @a start->kind or @a end->kind is @c svn_opt_revision_unspecified,
- * return the error @c SVN_ERR_CLIENT_BAD_REVISION. If any of the
- * revisions of @a path_or_url have a binary mime-type, return the
- * error @c SVN_ERR_CLIENT_IS_BINARY_FILE, unless @a ignore_mime_type is TRUE,
+ * return the error @c SVN_ERR_CLIENT_BAD_REVISION. If either are @c
+ * svn_opt_revision_working, return the error @c
+ * SVN_ERR_UNSUPPORTED_FEATURE. If any of the revisions of @a
+ * path_or_url have a binary mime-type, return the error @c
+ * SVN_ERR_CLIENT_IS_BINARY_FILE, unless @a ignore_mime_type is TRUE,
* in which case blame information will be generated regardless of the
* MIME types of the revisions.
--- subversion/libsvn_client/blame.c (revision 19556)
+++ subversion/libsvn_client/blame.c (working copy)
@@ -560,6 +560,11 @@
|| end->kind == svn_opt_revision_unspecified)
(SVN_ERR_CLIENT_BAD_REVISION, NULL, NULL);
+ else if (start->kind == svn_opt_revision_working
+ || end->kind == svn_opt_revision_working)
+ return svn_error_create
+ (SVN_ERR_UNSUPPORTED_FEATURE, NULL,
+ _("blame of the WORKING revision is not supported"));
/* Get an RA plugin for this filesystem object. */
> +1 on later adding support for blame of the working version. This means
> teaching the command-line client to accept 'WORKING' as a valid revision
> keyword (which it today does not). El cheapo feature to add to 'svn cat',
> too (for platform-ignorant catting of the working version).
+1 on eventually adding support for this. Exactly how the changes are
communicated to the user could use a little discussion. For example,
do we say all WORKING changes were made by the user performing the
'blame' operation (which might not be true in the case of a shared
WC), or do we use some generic text indicating that the changes are
specific to the WC (e.g. "(local)")? What to we use in place of the
Received on Mon May 8 20:42:13 2006
- application/pgp-signature attachment: stored