On Wed, Dec 17, 2008 at 11:05 AM, Paul Burba <ptburba_at_gmail.com> wrote:
> 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
Done. I've locally reintegrated the 1.5.x-reintegrate-improvements to
1.5.x and ran the [FSFS]x[LOCAL] tests with no failures.
One oddity, when I did the merge I got an unexpected conflict on merge.c:
>svn info
Path: .
URL: http://svn.collab.net/repos/svn/branches/1.5.x
Repository Root: http://svn.collab.net/repos/svn
Repository UUID: 612f8ebc-c883-4be0-9ee0-a4e9ef946e3a
Revision: 34802
Node Kind: directory
Schedule: normal
Last Changed Author: hwright
Last Changed Rev: 34799
Last Changed Date: 2008-12-17 15:20:41 -0500 (Wed, 17 Dec 2008)
>svn merge --reintegrate http://svn.collab.net/repos/svn/branches/1.5.x-reintegrate-improvements .
--- Merging differences between repository URLs into '.':
U STATUS
G www\images\subversion-diagram.png
G www\images\subversion_logo-200x173.png
G www\images\subversion_logo_hor-468x64.png
G www\images\subversion_logo-384x332.png
G COMMITTERS
G notes\tree-conflicts\scratch-pad.txt
U subversion\libsvn_fs_base\tree.c
U subversion\libsvn_fs_base\fs.c
U subversion\include\svn_mergeinfo.h
U subversion\include\svn_client.h
U subversion\include\private\svn_mergeinfo_private.h
G subversion\include\private
UG subversion\libsvn_wc\adm_ops.c
U subversion\libsvn_subr\mergeinfo.c
G subversion\libsvn_subr
Conflict discovered in 'subversion/libsvn_client/merge.c'.
Select: (p) postpone, (df) diff-full, (e) edit,
(mc) mine-conflict, (tc) theirs-conflict,
(s) show all options: p
CG subversion\libsvn_client\merge.c
U subversion\libsvn_client\ra.c
U subversion\libsvn_client\copy.c
G subversion\bindings\swig
U subversion\mod_dav_svn\mirror.c
U subversion\tests\cmdline\revert_tests.py
U subversion\tests\cmdline\copy_tests.py
U subversion\tests\cmdline\update_tests.py
UG subversion\tests\cmdline\svntest\actions.py
U subversion\tests\cmdline\merge_tests.py
U subversion\libsvn_ra_svn\cyrus_auth.c
U subversion\libsvn_ra_svn\internal_auth.c
U subversion\libsvn_ra_svn\ra_svn.h
G CHANGES
G .
Summary of conflicts:
Text conflicts: 1
The conflict was on the whole file:
>svn diff subversion\libsvn_client\merge.c
Index: subversion/libsvn_client/merge.c
===================================================================
--- subversion/libsvn_client/merge.c (revision 34802)
+++ subversion/libsvn_client/merge.c (working copy)
@@ -1,3 +1,4 @@
+<<<<<<< .working
/*
* merge.c: merging
*
@@ -7086,3 +7087,7473 @@
target_wcpath, recurse, ignore_ancestry, force,
dry_run, NULL, ctx, pool);
}
+=======
+/*
+ * merge.c: merging
<SNIP the whole right side file added>
+ target_wcpath, recurse, ignore_ancestry, force,
+ dry_run, NULL, ctx, pool);
+}
+>>>>>>> .merge-right.r34802
Since there were no changes to merge.c on 1.5.x since I last synched
1.5.x-reintegrate-improvements with it I just ran svn resolve --accept
theirs-full subversion\libsvn_client\merge.c and this gave what I
expected.
Anyone know what happened here? Am I missing something simple?
Paul
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=462&dsMessageId=986128
Received on 2008-12-18 00:04:09 CET