I was puzzled by this pair of lines in subversion/clients/cmdline/status-cmd.c:
/* We want our -u statuses to be against HEAD. */
rev.kind = svn_opt_revision_unspecified;
Asking for "unspecified" when we want "head"? After digging around I found this:
The command-line client specifically passes svn_opt_revision_unspecified as the "revision" parameter to svn_client_status when it really wants HEAD. I think this is because it knows that a network round-trip will be avoided; if it had asked for HEAD then svn_client_status would have used a round trip to convert that to a revision number to put in the request.
I think that the optimisation of not resolving HEAD to a number should be done within svn_client_status, and not its caller. The caller really wants HEAD in this case, and it should say so. The callee can know how to avoid the round trip in the case of HEAD.
[[[
Make svn_client_status optimise for status against HEAD, so its callers
don't have to know about that.
* subversion/libsvn_client/status.c
(svn_client_status) If status against HEAD is requested, don't bother
resolving to a particular revision number. We save a round trip by
just not specifying the revision number in the status request.
* subversion/clients/cmdline/status-cmd.c
(svn_cl__status) Because of the above, we can now specify that we want
the status against HEAD, which makes more sense than saying we want
the status against "unspecified".
]]]
Am I making sense here?
- Julian
Make svn_client_status optimise for status against HEAD, so its callers
don't have to know about that.
* subversion/libsvn_client/status.c
(svn_client_status) If status against HEAD is requested, don't bother
resolving to a particular revision number. We save a round trip by
just not specifying the revision number in the status request.
* subversion/clients/cmdline/status-cmd.c
(svn_cl__status) Because of the above, we can now specify that we want
the status against HEAD, which makes more sense than saying we want
the status against "unspecified".
Index: subversion/libsvn_client/status.c
===================================================================
--- subversion/libsvn_client/status.c (revision 7099)
+++ subversion/libsvn_client/status.c (working copy)
@@ -150,7 +150,6 @@
const char *URL;
svn_wc_adm_access_t *anchor_access;
svn_node_kind_t kind;
- svn_revnum_t revnum;
/* Using pool cleanup to close it. This needs to be recursive so that
auth data can be stored. */
@@ -199,10 +198,20 @@
else
{
svn_wc_adm_access_t *tgt_access;
-
- /* Get a revision number for our status operation. */
- SVN_ERR (svn_client__get_revision_number
- (&revnum, ra_lib, session, revision, target, pool));
+ svn_revnum_t revnum;
+
+ if (revision->kind == svn_opt_revision_head)
+ {
+ /* Cause the revision number to be omitted from the request,
+ which implies HEAD. */
+ revnum = SVN_INVALID_REVNUM;
+ }
+ else
+ {
+ /* Get a revision number for our status operation. */
+ SVN_ERR (svn_client__get_revision_number
+ (&revnum, ra_lib, session, revision, target, pool));
+ }
/* Do the deed. Let the RA layer drive the status editor. */
SVN_ERR (ra_lib->do_status (session, &reporter, &report_baton,
Index: subversion/clients/cmdline/status-cmd.c
===================================================================
--- subversion/clients/cmdline/status-cmd.c (revision 7099)
+++ subversion/clients/cmdline/status-cmd.c (working copy)
@@ -79,7 +79,7 @@
FALSE, pool));
/* We want our -u statuses to be against HEAD. */
- rev.kind = svn_opt_revision_unspecified;
+ rev.kind = svn_opt_revision_head;
/* The notification callback. */
svn_cl__get_notifier (&ctx->notify_func, &ctx->notify_baton, FALSE, FALSE,
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Sat Sep 20 00:32:57 2003