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.
* subversion/include/svn_client.h
(svn_client_blame3): Update doc string to reflect the new behavior.
* subversion/libsvn_client/blame.c
(svn_client_blame3): Return SVN_ERR_UNSUPPORTED_FEATURE for attempts
to call 'blame' on the WORKING revision.
Found by: Stefan Küng <tortoisesvn@gmail.com>
Suggested by: julianfoad, cmpilato
]]]
Index: subversion/include/svn_client.h
===================================================================
--- 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.
*
Index: subversion/libsvn_client/blame.c
===================================================================
--- subversion/libsvn_client/blame.c (revision 19556)
+++ subversion/libsvn_client/blame.c (working copy)
@@ -560,6 +560,11 @@
|| end->kind == svn_opt_revision_unspecified)
return svn_error_create
(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. */
SVN_ERR(svn_client__ra_session_from_path(&ra_session, &end_revnum,
> +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
revision?
--
Daniel Rall
- application/pgp-signature attachment: stored
Received on Mon May 8 20:42:13 2006