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);
}