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
> We could
> revert the merge, but if we do that, we should also revert r34748, which fixed
> test failures introduced as a result of the merge (the ol' exit_code problem).
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=462&dsMessageId=985814
Received on 2008-12-17 16:50:05 CET