On Wed, Dec 17, 2008 at 11:00 AM, Hyrum K. Wright
<hyrum_wright_at_mail.utexas.edu> wrote:
> 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?
Will do
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=462&dsMessageId=985837
Received on 2008-12-17 17:06:21 CET