Mailing-List: contact commits-help@subversion.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@subversion.apache.org
Content-Type: text/plain; charset="utf-8"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Subject: svn propchange: r1186252 - svn:log
Date: Wed, 19 Oct 2011 18:58:02 -0000
To: commits@subversion.apache.org
From: pburba@apache.org
Message-Id: <20111019185802.77EF42388847@eris.apache.org>

Author: pburba
Revision: 1186252
Modified property: svn:log

Modified: svn:log at Wed Oct 19 18:58:02 2011
------------------------------------------------------------------------------
--- svn:log (original)
+++ svn:log Wed Oct 19 18:58:02 2011
@@ -10,11 +10,18 @@ On the 1.7.x-r1180154 branch: Merge r118
   Clean merge.
 
 * subversion/libsvn_subr/mergeinfo.c
-  Got a lot of conflicts arising from the fact that r1149519 has not been
+  Got a lot of conflicts arising from the fact that r1149519, the only
+  relevant change to mergeinfo.c since we branched 1.7, has not been
   backported, nor can it be because it revved svn_rangelist_merge to 
-  svn_rangelist_merge2 and added add a scratch pool.  It also claimed to
+  svn_rangelist_merge2 adding a scratch pool.  r1149519 also claimed to
   modify the "rangelist in-place", but it didn't do all it could do on
   that front (hence r1180154).  Since r1180154 is effectively a full-on
-  reimplementation of svn_rangelist_merge2 these conflicts don't really
-  matter.  The only logical difference from r1180154 is that a local
-  subpool is used in in place of svn_rangelist_merge2's scratch_pool.
+  reimplementation of svn_rangelist_merge2 these conflicts can largely
+  be ignored.  After this commit the only difference between
+  svn_rangelist_merge2's implementation in
+  ^/subversion/trunk/subversion/libsvn_subr/mergeinfo.c@1186252
+  svn_rangelist_merge's implementation in
+  ^/subversion/branches/1.7.x-1180154/subversion/libsvn_subr/mergeinfo.c
+  @1186252 is that the latter uses a local subpool in place of a
+  passed-in scratch and takes apr_array_header_t **rangelist argument
+  rather than a apr_array_header_t *rangelist.