You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@subversion.apache.org by pb...@apache.org on 2013/04/12 18:38:33 UTC

svn commit: r1467341 - /subversion/trunk/subversion/libsvn_client/merge.c

Author: pburba
Date: Fri Apr 12 16:38:33 2013
New Revision: 1467341

URL: http://svn.apache.org/r1467341
Log:
* subversion/libsvn_client/merge.c
  (operative_rev_receiver): Add a comment explaining how what appears at
   first glance (to me at any rate) to be a bug, is actually not a problem.

Modified:
    subversion/trunk/subversion/libsvn_client/merge.c

Modified: subversion/trunk/subversion/libsvn_client/merge.c
URL: http://svn.apache.org/viewvc/subversion/trunk/subversion/libsvn_client/merge.c?rev=1467341&r1=1467340&r2=1467341&view=diff
==============================================================================
--- subversion/trunk/subversion/libsvn_client/merge.c (original)
+++ subversion/trunk/subversion/libsvn_client/merge.c Fri Apr 12 16:38:33 2013
@@ -12014,7 +12014,18 @@ operative_rev_receiver(void *baton,
   *operative_rev = log_entry->revision;
 
   /* We've found the youngest merged or oldest eligible revision, so
-     we're done. */
+     we're done...
+
+     ...but wait, shouldn't we care if LOG_ENTRY->NON_INHERITABLE is
+     true?  Because if it is, then LOG_ENTRY->REVISION is only
+     partially merged/elgibile!  And our only caller,
+     find_last_merged_location (via short_circuit_mergeinfo_log) is
+     interested in *fully* merged revisions.  That's all true, but if
+     find_last_merged_location() finds the youngest merged revision it
+     will also check for the oldest eligible revision.  So in the case
+     the youngest merged rev is non-inheritable, the *same* non-inheritable
+     rev will be found as the oldest eligible rev -- and
+     find_last_merged_location() handles that situation. */
   return svn_error_create(SVN_ERR_CEASE_INVOCATION, NULL, NULL);
 }