Paul Burba wrote:
> On Wed, Dec 17, 2008 at 10:06 AM, Hyrum K. Wright
> <hyrum_wright_at_mail.utexas.edu> wrote:
>> Julian Foad wrote:
>>> On Tue, 2008-12-16 at 13:50 -0600, Hyrum K. Wright wrote:
>>>> 1.5.x currently doesn't build due to the merge in r34734, with this log message:
>>>> ------------------------------------------------------------------------
>>>> r34734 | hwright | 2008-12-16 12:04:52 -0600 (Tue, 16 Dec 2008) | 15 lines
>>>>
>>>> Merge r34385, r34393 from trunk:
>>>>
>>>> * r34385, r34393
>>>> Fix broken merge when the merge target's natural history includes
>>>> resurrections.
>>>> Notes:
>>>> r34385 is a new test. r34393 is the fix.
>>>> Justification:
>>>> This problem was encountered 'in the wild' - see
>>>> http://svn.haxx.se/dev/archive-2008-11/0618.shtml. When encountered
>>>> cherry harvest merges are completely broken.
>>>> Votes:
>>>> +1: pburba, stylesen, cmpilato
>>>>
>>>>
>>>> It turns out that r34393 introduced a call to
>>>> svn_mergeinfo__get_range_endpoints(), which was introduced on trunk in r34306.
>>>> r34306 is currently awaiting review as part of the
>>>> 1.5.x-reintegrate-improvements branch.
>>>>
>>>> I created the 1.5.x-build-fixes branch to attempt to fix the build, but I think
>>>> that merging the reintegrate-improvements branch would be the better solution.
>>> On 1.5.x-build-fixes I get:
>>>
>>> subversion/libsvn_subr/mergeinfo.c:1501: no previous prototype for
>>> 'svn_mergeinfo__catalog_to_formatted_string'
>>> subversion/libsvn_subr/mergeinfo.c:1565: no previous prototype for
>>> 'svn_mergeinfo__to_formatted_string'
>>>
>>> Those two functions appear to be redundant in the 1.5.x-build-fixes
>>> branch. That means in one sense that the warnings are harmless, but in
>>> another sense it's wrong to include them because they are not part of
>>> the fix. They were added to that branch as part of r34740 and then a
>>> further change r34741 was made to support them.
>>>
>>> Shouldn't we revert the bad merge straight away? All this proposing to
>>> fix it, and voting on the fix, while the branch is still broken, is
>>> getting in the way of reviewing further back-ports.
>> My preference (and the correct way to do it, IIUC) is to merge the reintegrate
>> improvements, which includes r34306 in its entirety, to 1.5.x. That branch is
>> still lacking a +1, so maybe we should focus review efforts there.
>
> Ok, if the reintegrate improvements are backported we can do that,
> making all of this moot. Assuming they are not, then we can revert
> the "bad" merge of r34385 and r34393 and then I can renominate those
> changes along with (the parts? of) r34306 that are required.
>
> The only real question is how long to wait to find out if the
> reintegrate improvements are going in or not. Is anyone looking at
> those right now?
Paul,
I'm in the midst of merging the build-fixes branch to 1.5.x (running tests now)
so 1.5.x will be back to a stable state for further review. Given that there
may be conflicts between build-fixes and the reintegrate-improvements branch, do
you want to bring reintegrate-improvements up-to-date with 1.5.x after I merge?
-Hyrum
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=462&dsMessageId=985827
Received on 2008-12-17 17:00:58 CET