You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by Daniel Rall <dl...@collab.net> on 2006/01/14 22:15:46 UTC

[PATCH][Issue 2287] svn_client_log should take a peg revision

On Sat, 14 Jan 2006, Peter N. Lundblad wrote:

> I also find it easier (and more likely:-) to review patches sent to dev@
> and it is easier to reply with comments inline as well.
 
Here's what I attached to the issue (which pass log_tests.py), with a
change log.  I'll pick it back up on Monday.  Also, a few issues:

o The previous log function is passing its "end" parameter for
"peg_revision" (as done by svn_client_blame), but the doc string for
svn_client__open_ra_session_from_path makes me think that perhaps
svn_opt_revision_unspecified might be more appropriate?

o In the new call to svn_client__open_ra_session_from_path, the local
variable session_url is never used after being set.  What should be
done with it (e.g. replace base_url)?  Similarly, end_revnum is used,
but perhaps no longer exactly right.

o Peter suggested leaving svn_client_log() calling svn_client_log2().


[[[
* subversion/libsvn_client/log.c
  (svn_client_log3): New function based on the previous incarnation of
   svn_client_log2() which accepts a peg revision argument.

  (svn_client_log2): Delegate to svn_client_log3(), passing "end" for
   the "peg_revision" parameter.

  (svn_client_log): Delegate to svn_client_log3() instead of
   svn_client_log2() (in the same fashion as that function).


* subversion/include/svn_client.h
  (svn_client_log3): New declaration based on the previous incarnation
   of svn_client_log2() which accepts a peg revision argument.

  (svn_client_log2): Deprecated, and adjusted doc string.
]]]



Index: subversion/libsvn_client/log.c
===================================================================
--- subversion/libsvn_client/log.c	(revision 18103)
+++ subversion/libsvn_client/log.c	(working copy)
@@ -45,7 +45,8 @@
 
 
 svn_error_t *
-svn_client_log2 (const apr_array_header_t *targets,
+svn_client_log3 (const apr_array_header_t *targets,
+                 const svn_opt_revision_t *peg_revision,
                  const svn_opt_revision_t *start,
                  const svn_opt_revision_t *end,
                  int limit,
@@ -58,7 +59,7 @@
 {
   svn_ra_session_t *ra_session;
   const char *path;
-  const char *base_url;
+  const char *base_url, *session_url;
   const char *base_name = NULL;
   apr_array_header_t *condensed_targets;
   svn_revnum_t start_revnum, end_revnum;
@@ -159,11 +160,20 @@
 
   /* Open a repository session to the BASE_URL. */
   SVN_ERR (svn_path_condense_targets (&base_name, NULL, targets, TRUE, pool)); 
-  SVN_ERR (svn_client__open_ra_session_internal (&ra_session, base_url, 
-                                                 base_name, NULL, NULL,
-                                                 (NULL != base_name), TRUE, 
-                                                 ctx, pool));
+  /* ### This function duplicates some, but not all, of what
+     ### svn_client__ra_session_from_path() does.  Some of that
+     ### processing should be removed from this function to avoid
+     ### extra round-trips. Compare'em and see what needs to be
+     ### changed.
 
+     ### what are we going to do with session_url?
+
+     ### end_revnum shouldn't be set twice
+  */
+  SVN_ERR (svn_client__ra_session_from_path (&ra_session, &end_revnum,
+                                             &session_url, base_name,
+                                             peg_revision, end, ctx, pool));
+
   /* It's a bit complex to correctly handle the special revision words
    * such as "BASE", "COMMITTED", and "PREV".  For example, if the
    * user runs
@@ -194,7 +204,7 @@
       SVN_ERR (svn_client__get_revision_number
                (&start_revnum, ra_session, start, base_name, pool));
 
-    if (! end_is_local)
+    if (! end_is_local && end_revnum != SVN_INVALID_REVNUM)
       SVN_ERR (svn_client__get_revision_number
                (&end_revnum, ra_session, end, base_name, pool));
 
@@ -270,6 +280,23 @@
 }
 
 svn_error_t *
+svn_client_log2 (const apr_array_header_t *targets,
+                 const svn_opt_revision_t *start,
+                 const svn_opt_revision_t *end,
+                 int limit,
+                 svn_boolean_t discover_changed_paths,
+                 svn_boolean_t strict_node_history,
+                 svn_log_message_receiver_t receiver,
+                 void *receiver_baton,
+                 svn_client_ctx_t *ctx,
+                 apr_pool_t *pool)
+{
+  return svn_client_log3 (targets, end, start, end, limit,
+                          discover_changed_paths, strict_node_history,
+                          receiver, receiver_baton, ctx, pool);
+}
+
+svn_error_t *
 svn_client_log (const apr_array_header_t *targets,
                 const svn_opt_revision_t *start,
                 const svn_opt_revision_t *end,
@@ -282,7 +309,7 @@
 {
   svn_error_t *err = SVN_NO_ERROR;
 
-  err = svn_client_log2 (targets, start, end, 0, discover_changed_paths,
+  err = svn_client_log3 (targets, end, start, end, 0, discover_changed_paths,
                          strict_node_history, receiver, receiver_baton, ctx,
                          pool);
     
Index: subversion/include/svn_client.h
===================================================================
--- subversion/include/svn_client.h	(revision 18103)
+++ subversion/include/svn_client.h	(working copy)
@@ -1177,7 +1177,8 @@
  * for which log messages are desired.  The repository info is
  * determined by taking the common prefix of the target entries' URLs.
  * @a receiver is invoked only on messages whose revisions involved a
- * change to some path in @a targets.
+ * change to some path in @a targets.  @a peg_revision indicates in
+ * which revision @a targets are valid.
  *
  * If @a limit is non-zero only invoke @a receiver on the first @a limit
  * logs.
@@ -1202,6 +1203,27 @@
  * If @a ctx->notify_func2 is non-null, then call @a ctx->notify_func2/baton2
  * with a 'skip' signal on any unversioned targets.
  *
+ * @since New in 1.4.
+ */
+svn_error_t *
+svn_client_log3 (const apr_array_header_t *targets,
+                 const svn_opt_revision_t *peg_revision,
+                 const svn_opt_revision_t *start,
+                 const svn_opt_revision_t *end,
+                 int limit,
+                 svn_boolean_t discover_changed_paths,
+                 svn_boolean_t strict_node_history,
+                 svn_log_message_receiver_t receiver,
+                 void *receiver_baton,
+                 svn_client_ctx_t *ctx,
+                 apr_pool_t *pool);
+
+
+/**
+ * Similar to svn_client_log3(), but with the @a peg_revision
+ * parameter set to @c end.
+ *
+ * @deprecated Provided for backward compatibility with the 1.2 API.
  * @since New in 1.2.
  */
 svn_error_t *


...
> I reviewed and S.Ramaswamy posted another patch with some good stuff
> in it. Did you look at it?  (I haven't looked at your latest patch,
> so I don't know.)

No, I didn't see it.  Way back on Jun 29 -- okay, I'll take a look, thanks.
-- 

Daniel Rall

Re: [PATCH][Issue 2287] svn_client_log should take a peg revision

Posted by Peter Samuelson <pe...@p12n.org>.
[Malcolm Rowe]
> Excellent.  What should the behaviour of 'svn log foo@PEG' be, if no
> revision range is provided?  Should it still be -rHEAD:1, as it is now
> (I think), or should it be -rPEG:1, which might be more in-line with
> the other commands that operate on peg-revs.

-rPEG:1 makes more sense to me, a humble user.  There's certainly a
case to be made for each, though.

Re: [PATCH][Issue 2287] svn_client_log should take a peg revision

Posted by Daniel Rall <dl...@collab.net>.
On Wed, 25 Jan 2006, Daniel Rall wrote:

> On Wed, 25 Jan 2006, Daniel Rall wrote:
> 
> > On Tue, 24 Jan 2006, Malcolm Rowe wrote:
...
> > > Excellent.  What should the behaviour of 'svn log foo@PEG' be, if no
> > > revision range is provided?  Should it still be -rHEAD:1, as it is now
> > > (I think), or should it be -rPEG:1, which might be more in-line with
> > > the other commands that operate on peg-revs.
> > > 
> > > See http://svn.haxx.se/dev/archive-2006-01/0352.shtml for an equivalent
> > > patch I proposed for 'svn blame', though note here that we have no
> > > backward-compatibility concerns.
> > 
> > As Peter Samuelson, I prefer PEG to HEAD on the grounds of both
> > consistency and usability.  I'll come up with a XFail regression test
> > for 'svn log' to get us started.
> 
> Here's a patch adding that function to the command-line client (I
> assume we want it there, rather than in the library itself?), and some
> related tests.  If there are no comments, I'll commit it RSN.

Committed in r18255.
--

Daniel Rall

Re: [PATCH][Issue 2287] svn_client_log should take a peg revision

Posted by Daniel Rall <dl...@collab.net>.
On Wed, 25 Jan 2006, Daniel Rall wrote:

> On Tue, 24 Jan 2006, Malcolm Rowe wrote:
> 
> > On Thu, Jan 19, 2006 at 01:35:22PM -0800, Daniel Rall wrote:
> > > I've committed a patch adding support for peg revisions to 'svn log'
> > > (and of course the corresponding underlying APIs), based on work by
> > > myself and Ramaswamy (and all the reviews that work received):
> > > 
> > > http://svn.collab.net/viewcvs/svn?rev=18179&view=rev
> > > 
> > > This feature should first be available in Subversion 1.4.0.
> > 
> > Excellent.  What should the behaviour of 'svn log foo@PEG' be, if no
> > revision range is provided?  Should it still be -rHEAD:1, as it is now
> > (I think), or should it be -rPEG:1, which might be more in-line with
> > the other commands that operate on peg-revs.
> > 
> > See http://svn.haxx.se/dev/archive-2006-01/0352.shtml for an equivalent
> > patch I proposed for 'svn blame', though note here that we have no
> > backward-compatibility concerns.
> 
> As Peter Samuelson, I prefer PEG to HEAD on the grounds of both
> consistency and usability.  I'll come up with a XFail regression test
> for 'svn log' to get us started.

Here's a patch adding that function to the command-line client (I
assume we want it there, rather than in the library itself?), and some
related tests.  If there are no comments, I'll commit it RSN.

[[[
Make 'svn log target@N' consistent with the peg revision operations of
other commands (e.g. 'svn cat target@N'), where the specified peg
revision becomes the virtual HEAD.  See
http://svn.haxx.se/dev/archive-2006-01/0352.shtml for related
discussion, or http://svn.collab.net/viewcvs/svn?rev=18179&view=rev
for a related patch (to 'svn blame').  Because peg revision handling
for 'svn log' is new in Subversion 1.4, there are no compatibility
concerns here.


* subversion/tests/cmdline/log_tests.py
  (log_wc_with_peg_revision): New function testing log of a WC target
   with a peg revision.

  (url_missing_in_head): Remove redundant -rN from command (now
   implied by @N peg revision on URI), and improve validation by
   parsing the log output.

  (test_list): Add log_wc_with_peg_revision() to the list.


* subversion/svn/log-cmd.c
  (svn_cl__log): When OPT_STATE->START_REVISION is not specified and
   START_REVISION PEG_REVISION is specified, set
   OPT_STATE->START_REVISION to PEG_REVISION.


Suggested by: malcolm
              Peter Samuelson
]]]

Index: subversion/tests/cmdline/log_tests.py
===================================================================
--- subversion/tests/cmdline/log_tests.py	(revision 18242)
+++ subversion/tests/cmdline/log_tests.py	(working copy)
@@ -528,15 +528,25 @@
     os.chdir(was_cwd)
 
 #----------------------------------------------------------------------
+def log_wc_with_peg_revision(sbox):
+  "'svn log wc_target@N'"
+  guarantee_repos_and_wc(sbox)
+  my_path = os.path.join(sbox.wc_dir, "A", "B", "E", "beta") + "@8"
+  output, err = svntest.actions.run_and_verify_svn(None, None, [],
+                                                   'log', my_path)
+  check_log_chain(parse_log_output(output), [1])
+
+#----------------------------------------------------------------------
 def url_missing_in_head(sbox):
-  "'svn log -r N URL' when URL is not in HEAD "
+  "'svn log target@N' when target removed from HEAD"
 
   guarantee_repos_and_wc(sbox)
 
   my_url = svntest.main.current_repo_url + "/A/B/E/alpha" + "@8"
   
-  svntest.actions.run_and_verify_svn(None, None, [],
-                                     'log', '-r', '8', my_url)
+  output, err = svntest.actions.run_and_verify_svn(None, None, [],
+                                                   'log', my_url)
+  check_log_chain(parse_log_output(output), [3, 1])
 
 #----------------------------------------------------------------------
 def log_through_copyfrom_history(sbox):
@@ -781,6 +791,7 @@
               log_to_revision_zero,
               dynamic_revision,
               log_with_path_args,
+              log_wc_with_peg_revision,
               url_missing_in_head,
               log_through_copyfrom_history,
               escape_control_chars,
Index: subversion/svn/log-cmd.c
===================================================================
--- subversion/svn/log-cmd.c	(revision 18242)
+++ subversion/svn/log-cmd.c	(working copy)
@@ -420,12 +420,18 @@
     }
   else if (opt_state->start_revision.kind == svn_opt_revision_unspecified)
     {
-      /* If the first target is a URL, then we default to HEAD:0.
-         Otherwise, the default is BASE:0 since WC@HEAD may not exist. */
-      if (svn_path_is_url (target))
-        opt_state->start_revision.kind = svn_opt_revision_head;
+      /* Default to any specified peg revision.  Otherwise, if the
+         first target is an URL, then we default to HEAD:0.  Lastly,
+         the default is BASE:0 since WC@HEAD may not exist. */
+      if (peg_revision.kind == svn_opt_revision_unspecified)
+        {
+          if (svn_path_is_url (target))
+            opt_state->start_revision.kind = svn_opt_revision_head;
+          else
+            opt_state->start_revision.kind = svn_opt_revision_base;
+        }
       else
-        opt_state->start_revision.kind = svn_opt_revision_base;
+        opt_state->start_revision = peg_revision;
 
       if (opt_state->end_revision.kind == svn_opt_revision_unspecified)
         {

Re: [PATCH][Issue 2287] svn_client_log should take a peg revision

Posted by Daniel Rall <dl...@collab.net>.
On Tue, 24 Jan 2006, Malcolm Rowe wrote:

> On Thu, Jan 19, 2006 at 01:35:22PM -0800, Daniel Rall wrote:
> > I've committed a patch adding support for peg revisions to 'svn log'
> > (and of course the corresponding underlying APIs), based on work by
> > myself and Ramaswamy (and all the reviews that work received):
> > 
> > http://svn.collab.net/viewcvs/svn?rev=18179&view=rev
> > 
> > This feature should first be available in Subversion 1.4.0.
> 
> Excellent.  What should the behaviour of 'svn log foo@PEG' be, if no
> revision range is provided?  Should it still be -rHEAD:1, as it is now
> (I think), or should it be -rPEG:1, which might be more in-line with
> the other commands that operate on peg-revs.
> 
> See http://svn.haxx.se/dev/archive-2006-01/0352.shtml for an equivalent
> patch I proposed for 'svn blame', though note here that we have no
> backward-compatibility concerns.

As Peter Samuelson, I prefer PEG to HEAD on the grounds of both
consistency and usability.  I'll come up with a XFail regression test
for 'svn log' to get us started.
-- 

Daniel Rall

Re: [PATCH][Issue 2287] svn_client_log should take a peg revision

Posted by Malcolm Rowe <ma...@farside.org.uk>.
On Thu, Jan 19, 2006 at 01:35:22PM -0800, Daniel Rall wrote:
> I've committed a patch adding support for peg revisions to 'svn log'
> (and of course the corresponding underlying APIs), based on work by
> myself and Ramaswamy (and all the reviews that work received):
> 
> http://svn.collab.net/viewcvs/svn?rev=18179&view=rev
> 
> This feature should first be available in Subversion 1.4.0.

Excellent.  What should the behaviour of 'svn log foo@PEG' be, if no
revision range is provided?  Should it still be -rHEAD:1, as it is now
(I think), or should it be -rPEG:1, which might be more in-line with
the other commands that operate on peg-revs.

See http://svn.haxx.se/dev/archive-2006-01/0352.shtml for an equivalent
patch I proposed for 'svn blame', though note here that we have no
backward-compatibility concerns.

Regards,
Malcolm

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

Re: [PATCH][Issue 2287] svn_client_log should take a peg revision

Posted by Daniel Rall <dl...@collab.net>.
On Tue, 24 Jan 2006, Daniel Rall wrote:
...
> How about changing things like below, renaming PATH to
> BASE_URL_OR_PATH, and using it both when condensing the targets and
> when opening the RA session.  This only seems necessary when TARGETS
> contain multiple local paths, which can only occur via direct API
> access (the 'svn' command-line client doesn't support this).  This
> passes log_tests.py over ra_local.

I committed a similar fix in r18241.
-- 

Daniel Rall

Re: [PATCH][Issue 2287] svn_client_log should take a peg revision

Posted by Daniel Rall <dl...@collab.net>.
On Tue, 24 Jan 2006, Daniel Rall wrote:

> On Tue, 24 Jan 2006, Julian Foad wrote:
...
> > Note: some confusion may result from the fact that, as far as I recall, 
> > this log function has never worked properly for multiple local paths.  We 
> > (I) changed our command-line client to not support that usage, but it seems 
> > we didn't fix the problem in the API.  I don't know whether that affects 
> > any of the issues below.
> > 
> > >       /* Find the base URL and condensed targets relative to it. */
> > >-      SVN_ERR (svn_path_condense_targets (&base_url, &condensed_targets,
> > >+      SVN_ERR (svn_path_condense_targets (&ignored_url, 
> > >&condensed_targets,
> > >                                           target_urls, TRUE, pool));
> > 
> > I don't see how it can be right to ignore the base URL determined by that 
> > function and yet use the condensed targets that are relative to that base.
> 
> PATH is currently passed to svn_client__ra_session_from_path(), after
> being set to the first target.  At least for the command-line client,
> this is correct for the URI case, where any URI required to be the
> first target.  Is this also correct when svn_client_log3() is used as
> an API (not by the command-line client)?
> 
> This certainly does seem questionable for local paths, where the
> path's ".svn/entries" file is eventually used to procure its URI (via
> svn_client_url_from_path).  If multiple local paths to different
> directories are specified in the TARGETS argument, will the wrong base
> URI be inferred when opening the RA session?

How about changing things like below, renaming PATH to
BASE_URL_OR_PATH, and using it both when condensing the targets and
when opening the RA session.  This only seems necessary when TARGETS
contain multiple local paths, which can only occur via direct API
access (the 'svn' command-line client doesn't support this).  This
passes log_tests.py over ra_local.

- Dan


Index: subversion/libsvn_client/log.c
===================================================================
--- subversion/libsvn_client/log.c      (revision 18211)
+++ subversion/libsvn_client/log.c      (working copy)
@@ -58,7 +58,7 @@
                  apr_pool_t *pool)
 {
   svn_ra_session_t *ra_session;
-  const char *path;
+  const char *base_url_or_path;
   const char *ignored_url;
   const char *base_name = NULL;
   apr_array_header_t *condensed_targets;
@@ -73,10 +73,10 @@
          _("Missing required revision specification"));
     }

-  path = (APR_ARRAY_IDX(targets, 0, const char *));
+  base_url_or_path = (APR_ARRAY_IDX(targets, 0, const char *));

   /* Use the passed URL, if there is one.  */
-  if (svn_path_is_url (path))
+  if (svn_path_is_url (base_url_or_path))
     {
       /* Initialize this array, since we'll be building it below */
       condensed_targets = apr_array_make (pool, 1, sizeof (const char *));
@@ -143,7 +143,8 @@
         return SVN_NO_ERROR;

       /* Find the base URL and condensed targets relative to it. */
-      SVN_ERR (svn_path_condense_targets (&ignored_url, &condensed_targets,
+      SVN_ERR (svn_path_condense_targets (&base_url_or_path,
+                                          &condensed_targets,
                                           target_urls, TRUE, pool));

       if (condensed_targets->nelts == 0)
@@ -166,8 +167,9 @@
     session_opt_rev.kind = svn_opt_revision_unspecified;

   SVN_ERR (svn_client__ra_session_from_path (&ra_session, &ignored_revnum,
-                                             &ignored_url, path, peg_revision,
-                                             &session_opt_rev, ctx, pool));
+                                             &ignored_url, base_url_or_path,
+                                             peg_revision, &session_opt_rev,
+                                             ctx, pool));

   /* It's a bit complex to correctly handle the special revision words
    * such as "BASE", "COMMITTED", and "PREV".  For example, if the

Re: [PATCH][Issue 2287] svn_client_log should take a peg revision

Posted by Daniel Rall <dl...@collab.net>.
On Tue, 24 Jan 2006, Julian Foad wrote:

> Daniel Rall wrote:
...
> >http://svn.collab.net/viewcvs/svn?rev=18179&view=rev
...
> We have to pay a bit of attention to the details that seem to be 
> unfinished.  I think you asked some questions and didn't get any answers.

Yeah.  I spent quite a bit of time looking into them, but didn't come
up with entirely satisfactory answers for all of them.

> Note: some confusion may result from the fact that, as far as I recall, 
> this log function has never worked properly for multiple local paths.  We 
> (I) changed our command-line client to not support that usage, but it seems 
> we didn't fix the problem in the API.  I don't know whether that affects 
> any of the issues below.
> 
> >       /* Find the base URL and condensed targets relative to it. */
> >-      SVN_ERR (svn_path_condense_targets (&base_url, &condensed_targets,
> >+      SVN_ERR (svn_path_condense_targets (&ignored_url, 
> >&condensed_targets,
> >                                           target_urls, TRUE, pool));
> 
> I don't see how it can be right to ignore the base URL determined by that 
> function and yet use the condensed targets that are relative to that base.

PATH is currently passed to svn_client__ra_session_from_path(), after
being set to the first target.  At least for the command-line client,
this is correct for the URI case, where any URI required to be the
first target.  Is this also correct when svn_client_log3() is used as
an API (not by the command-line client)?

This certainly does seem questionable for local paths, where the
path's ".svn/entries" file is eventually used to procure its URI (via
svn_client_url_from_path).  If multiple local paths to different
directories are specified in the TARGETS argument, will the wrong base
URI be inferred when opening the RA session?

> >+  /* Determine the revision to open the RA session to. */
> >+  if (start->kind == svn_opt_revision_number &&
> >+      end->kind == svn_opt_revision_number)
> >+    session_opt_rev = (start->value.number > end->value.number ?
> >+                       *start : *end);
> >+  else if (start->kind == svn_opt_revision_date &&
> >+           end->kind == svn_opt_revision_date)
> >+    session_opt_rev = (start->value.date > end->value.date ? *start : 
> >*end);
> >+  else
> >+    session_opt_rev.kind = svn_opt_revision_unspecified;
> 
> I don't see how that can make sense.  This seems to say: if the two 
> revisions were specified by the user in different ways then we don't need 
> to specify what revision to open the RA session to; yet if they are both 
> numbers or both dates then we should use the later.  Please explain why.
>
> All I can think of, if this is correct, is that specifying the later 
> revision is an optimisation or "hint" but is not actually necessary.

This change is from Ramaswamy's latest patch -- you asked him similar
questions in your previous reviews during the patch's evolution.  This
is the most informative one:

http://svn.haxx.se/dev/archive-2005-09/0281.shtml

I too puzzled over this change, and given the help of the test suite
came to the conclusion that it must be right.  See
log_tests.py:url_missing_in_head(), which uses r8 of "alpha" as a peg
revision.  "alpha" is removed in r9, and IIRC, without that block, the
test fails (Ram mentions something similar in his response at the URL
above).  I think this code needs an in-line comment...suggestions?

WRT using a later revision number or date goes, this was the intent of
my use of the svn_opt_revision_t END argument to
svn_client__ra_session_from_path() from the early incarnations of my
patch (at first foolishly assuming that END would always be younger),
following the example of svn_client_blame2().  'svn blame' has a
different enough implementation that it was not clear whether it
needed any similar processing.

...
> "@peg_revision" -> "@a peg_revision"

r18212, thanks.

> You wrote, with an earlier draft of the patch:
> >o The previous log function is passing its "end" parameter for
> >"peg_revision" (as done by svn_client_blame), but the doc string for
> >svn_client__open_ra_session_from_path makes me think that perhaps
> >svn_opt_revision_unspecified might be more appropriate?
> 
> You're talking about your new (tiny, forwarding) version of 
> svn_client_log2() calling svn_client_log3(), passing "end" for 
> "peg_revision" in that earlier patch, or, in the version you checked in, 
> passing "svn_opt_revision_unspecified" for "peg_revision".  I hope you have 
> determined that the latter preserves svn_client_log2()'s existing 
> behaviour; I haven't checked.

Yes, and I checked.  It was documented to do so (by you :) after this
came up in discussion of Ram's original patches:

http://svn.collab.net/viewcvs/svn?rev=16034&view=rev
 
> >o In the new call to [svn_client__ra_session_from_path], the local
> >variable session_url is never used after being set.  What should be
> >done with it (e.g. replace base_url)?  Similarly, end_revnum is used,
> >but perhaps no longer exactly right.
> 
> (... In the checked-in code, you have called these two results
> "ignored_url" and "ignored_revnum" respectively.)
> 
> Hmm.  I don't know.  I could believe that they might not be needed but we 
> need someone else to check it (or me to spend more time on it :-).

I experimented with using what's now named IGNORED_REVNUM in place of
START_REVNUM or END_REVNUM, but the values didn't necessarily match
up, and it was simpler to continue calling
svn_client__get_revision_number().  If someone was able to
successfully make use of IGNORED_REVNUM, changing this could be a
perfomance enhancement, but would also add to code complexity.
 
IGNORED_URL discussed above.

> >o Peter suggested leaving svn_client_log() calling svn_client_log2().
> 
> ... rather than changing it to call svn_client_log3() directly.  The 
> overhead of an extra call is totally insignificant in this context, so I 
> would choose whichever is easiest to understand and maintain, which would 
> probably be calling svn_client_log2(), but in this case it doesn't make 
> much difference so what you checked in is fine.

I considered the same factors after Peter Lundblad's suggestion, and
decided to have svn_client_log() delegate to svn_client_log2() on the
basis that it is 1) simpler to maintain and 2) resulted in less code
change.
-- 

Daniel Rall

Re: [PATCH][Issue 2287] svn_client_log should take a peg revision

Posted by Julian Foad <ju...@btopenworld.com>.
Daniel Rall wrote:
> I've committed a patch adding support for peg revisions to 'svn log'
> (and of course the corresponding underlying APIs), based on work by
> myself and Ramaswamy (and all the reviews that work received):
> 
> http://svn.collab.net/viewcvs/svn?rev=18179&view=rev

OK.  It's certainly good to have this.

We have to pay a bit of attention to the details that seem to be unfinished.  I 
think you asked some questions and didn't get any answers.

Note: some confusion may result from the fact that, as far as I recall, this 
log function has never worked properly for multiple local paths.  We (I) 
changed our command-line client to not support that usage, but it seems we 
didn't fix the problem in the API.  I don't know whether that affects any of 
the issues below.


>        /* Find the base URL and condensed targets relative to it. */
> -      SVN_ERR (svn_path_condense_targets (&base_url, &condensed_targets,
> +      SVN_ERR (svn_path_condense_targets (&ignored_url, &condensed_targets,
>                                            target_urls, TRUE, pool));

I don't see how it can be right to ignore the base URL determined by that 
function and yet use the condensed targets that are relative to that base.


> +  /* Determine the revision to open the RA session to. */
> +  if (start->kind == svn_opt_revision_number &&
> +      end->kind == svn_opt_revision_number)
> +    session_opt_rev = (start->value.number > end->value.number ?
> +                       *start : *end);
> +  else if (start->kind == svn_opt_revision_date &&
> +           end->kind == svn_opt_revision_date)
> +    session_opt_rev = (start->value.date > end->value.date ? *start : *end);
> +  else
> +    session_opt_rev.kind = svn_opt_revision_unspecified;

I don't see how that can make sense.  This seems to say: if the two revisions 
were specified by the user in different ways then we don't need to specify what 
revision to open the RA session to; yet if they are both numbers or both dates 
then we should use the later.  Please explain why.  All I can think of, if this 
is correct, is that specifying the later revision is an optimisation or "hint" 
but is not actually necessary.


> Index: subversion/include/svn_client.h
> ===================================================================
> --- subversion/include/svn_client.h     (revision 18178)
> +++ subversion/include/svn_client.h     (revision 18179)
> @@ -1177,7 +1177,11 @@
>   * for which log messages are desired.  The repository info is
>   * determined by taking the common prefix of the target entries' URLs.
>   * @a receiver is invoked only on messages whose revisions involved a
> - * change to some path in @a targets.
> + * change to some path in @a targets.  @a peg_revision indicates in
> + * which revision @a targets are valid.  If @peg_revision is @c

"@peg_revision" -> "@a peg_revision"


You wrote, with an earlier draft of the patch:
> o The previous log function is passing its "end" parameter for
> "peg_revision" (as done by svn_client_blame), but the doc string for
> svn_client__open_ra_session_from_path makes me think that perhaps
> svn_opt_revision_unspecified might be more appropriate?

You're talking about your new (tiny, forwarding) version of svn_client_log2() 
calling svn_client_log3(), passing "end" for "peg_revision" in that earlier 
patch, or, in the version you checked in, passing 
"svn_opt_revision_unspecified" for "peg_revision".  I hope you have determined 
that the latter preserves svn_client_log2()'s existing behaviour; I haven't 
checked.

> o In the new call to svn_client__open_ra_session_from_path, the local
> variable session_url is never used after being set.  What should be
> done with it (e.g. replace base_url)?  Similarly, end_revnum is used,
> but perhaps no longer exactly right.

(The function is called svn_client__ra_session_from_path().  In the checked-in 
code, you have called these two results "ignored_url" and "ignored_revnum" 
respectively.)

Hmm.  I don't know.  I could believe that they might not be needed but we need 
someone else to check it (or me to spend more time on it :-).

> o Peter suggested leaving svn_client_log() calling svn_client_log2().

... rather than changing it to call svn_client_log3() directly.  The overhead 
of an extra call is totally insignificant in this context, so I would choose 
whichever is easiest to understand and maintain, which would probably be 
calling svn_client_log2(), but in this case it doesn't make much difference so 
what you checked in is fine.


- Julian

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

Re: [PATCH][Issue 2287] svn_client_log should take a peg revision

Posted by Daniel Rall <dl...@collab.net>.
I've committed a patch adding support for peg revisions to 'svn log'
(and of course the corresponding underlying APIs), based on work by
myself and Ramaswamy (and all the reviews that work received):

http://svn.collab.net/viewcvs/svn?rev=18179&view=rev

This feature should first be available in Subversion 1.4.0.
-- 

Daniel Rall