RE: RE: svn commit: r26803 - in trunk/subversion: libsvn_client tests/cmdline

> -----Original Message-----
> From: Paul Burba [mailto:pburba@collab.net]
> Sent: Thursday, October 04, 2007 12:32 PM
> To: dev@subversion.tigris.org; kameshj@tigris.org
> Cc: Lieven Govaerts
> Subject: RE: svn commit: r26803 - in trunk/subversion:
> libsvn_client tests/cmdline
>
> > -----Original Message-----
> > From: Kamesh Jayachandran
> > Sent: Saturday, September 29, 2007 3:20 PM
> > To: Paul Burba; dev@subversion.tigris.org; kameshj@tigris.org
> > Subject: RE: svn commit: r26803 - in trunk/subversion:
> > libsvn_client tests/cmdline
> >
> > >> > * excepting "merge_tests.py 63: merge fails if subtree is
> > >> deleted on
> > >> > src", which has been failing since r26803.
> > >>
> >
> > >Kamesh - the Win32 buildbots have the details:
> >
> > >http://www.mobsol.be/buildbot/win32-xp%20VS2005/builds/2379/s
> > tep-Test%2
> > >0fsfs%2Bra_local/0
> >
> > >Paul
> >
> > Paul,
> >
> > Some thoughts on this failure.
> > Something needs to be done in our testsuite to fix this.
> >
> > expected_merge_output does atleast one match with the regex
> > * In linux we did not catch this as actual merge output
> > 'D
> > svn-test-work/working_copies/merge_tests-63/A_copy/D/gamma'
> > did match the regex while the merge notification did not
> match due to
> > r26803.
>
> But if it did not match on Linux, why has this test been
> passing on Linux?
>
> > * In windows somehow
> > 'D
> > svn-test-work\working_copies\merge_tests-63\A_copy\D\gamma'
> > did not match with the regex.
> >
> > You may ask how does it work with other 'expected_merge_output',
> > Almost in all the use of 'expected_merge_output' it
> happened to be for
> > 'single file merging' which still uses a old style. In
> other few cases
> > where we use 'expected_merge_output' we do use it for short
> revision
> > range which does merge range for same revs as the old style.
> >
> > Quick fix would be to change the expectation as matching
> with the new
> > style, like the following patch.
> > More proper fix would be to analyse and fix why the path does not
> > match in win32 as it does in Linux.
>
> Lieven, on IRC you mentioned:
>
> "pburba: looking at the test output I think that the only
> problem is that '.+' in python's regex on Windows doesn't
> match backslashes, where on *nix it matches '/'."
>
> In the interest of follow-up it seems that '.+' does handle
> back slashes correctly on Win32, e.g.:
>
> >>> import re
> >>> regexp = re.compile("--- Merging r3 through r5 into '.+':")
> >>> regexp.match("--- Merging r3 DONT MATCH through r5 into
> 'SOME\\PATH':")
> >>>
> >>> regexp.match("--- Merging r3 through r5 into 'SOME/PATH':")
> <_sre.SRE_Match object at 0x01202950>
> >>> regexp.match("--- Merging r3 through r5 into 'SOME\PATH':")
> <_sre.SRE_Match object at 0x01202528>
> >>> regexp.match("--- Merging r3 through r5 into 'SOME\\PATH':")
> <_sre.SRE_Match object at 0x01202950>
> >>>
>
> > Still we may need the
> > following patch as a matter of completeness.
>
> <snip>
>
> > - svntest.actions.run_and_verify_svn(None, expected_merge_output(3,
> > + svntest.actions.run_and_verify_svn(None, expected_merge_output(2,
>
> (Kamesh noted off list that this change is incorrect, since
> r2 is already present, rather it is the notification that is wrong.)
>
> That "wrongness" is illustrated here:
>
> >svn st merge_tests-1 -v
> 1 1 jrandom merge_tests-1
> 1 1 jrandom merge_tests-1\A
> 1 1 jrandom merge_tests-1\A\B
> 1 1 jrandom merge_tests-1\A\B\lambda
> 1 1 jrandom merge_tests-1\A\B\E
> 1 1 jrandom merge_tests-1\A\B\E\alpha
> 5 5 jrandom merge_tests-1\A\B\E\beta
> 1 1 jrandom merge_tests-1\A\B\F
> 1 1 jrandom merge_tests-1\A\mu
> 1 1 jrandom merge_tests-1\A\C
> 1 1 jrandom merge_tests-1\A\D
> 1 1 jrandom merge_tests-1\A\D\gamma
> 1 1 jrandom merge_tests-1\A\D\G
> 1 1 jrandom merge_tests-1\A\D\G\pi
> 4 4 jrandom merge_tests-1\A\D\G\rho
> 1 1 jrandom merge_tests-1\A\D\G\tau
> 1 1 jrandom merge_tests-1\A\D\H
> 1 1 jrandom merge_tests-1\A\D\H\chi
> 6 6 jrandom merge_tests-1\A\D\H\omega
> 3 3 jrandom merge_tests-1\A\D\H\psi
> 2 2 jrandom merge_tests-1\A_COPY
> 2 2 jrandom merge_tests-1\A_COPY\B
> 2 2 jrandom
> merge_tests-1\A_COPY\B\lambda
> 2 2 jrandom merge_tests-1\A_COPY\B\E
> 2 2 jrandom
> merge_tests-1\A_COPY\B\E\alpha
> 2 2 jrandom
> merge_tests-1\A_COPY\B\E\beta
> 2 2 jrandom merge_tests-1\A_COPY\B\F
> 2 2 jrandom merge_tests-1\A_COPY\mu
> 2 2 jrandom merge_tests-1\A_COPY\C
> 2 2 jrandom merge_tests-1\A_COPY\D
> 2 2 jrandom merge_tests-1\A_COPY\D\gamma
> 2 2 jrandom merge_tests-1\A_COPY\D\G
> 2 2 jrandom merge_tests-1\A_COPY\D\G\pi
> 2 2 jrandom merge_tests-1\A_COPY\D\G\rho
> 2 2 jrandom merge_tests-1\A_COPY\D\G\tau
> 2 2 jrandom merge_tests-1\A_COPY\D\H
> 2 2 jrandom merge_tests-1\A_COPY\D\H\chi
> 2 2 jrandom
> merge_tests-1\A_COPY\D\H\omega
> 2 2 jrandom merge_tests-1\A_COPY\D\H\psi
> 1 1 jrandom merge_tests-1\iota
>
> >svn pl -vR merge_tests-1
> Properties on 'merge_tests-1\A_COPY':
> svn:mergeinfo : /A:1
>
> ### WE EXPECT AND SEE NOTIFICATION FOR r4-5 INCLUSIVE...
> >svn merge -r3:5 %URL%/A/D merge_tests-1\A_COPY\D
> --- Merging r4 through r5 into 'merge_tests-1\A_COPY\D':
> U merge_tests-1\A_COPY\D\G\rho
>
> >svn pl -vR merge_tests-1
> Properties on 'merge_tests-1\A_COPY':
> svn:mergeinfo : /A:1
> Properties on 'merge_tests-1\A_COPY\D':
> svn:mergeinfo : /A/D:1,4-5
>
> ### ...NOW REPEAT A SUPERSET OF THE PREVIOUS MERGE RANGE
> >svn merge -r2:6 %URL%/A/D merge_tests-1\A_COPY\D
> ### THIS LOOKS FINE, JUST r2
> --- Merging r3 into 'merge_tests-1\A_COPY\D':
> U merge_tests-1\A_COPY\D\H\psi
> ### BUT SHOULDN'T THIS BE *JUST* r6 IN THE NOTIFICATION?
> --- Merging r4 through r6 into 'merge_tests-1\A_COPY\D':
> U merge_tests-1\A_COPY\D\H\omega
>
> ### AT LEAST THE MERGEINFO IS RIGHT :-)
> >svn pl -vR merge_tests-1
> Properties on 'merge_tests-1\A_COPY':
> svn:mergeinfo : /A:1
> Properties on 'merge_tests-1\A_COPY\D':
> svn:mergeinfo : /A/D:1,3-6
>
> Kamesh is looking into this problem...and speaking of, I did
> notice that in the case where the second merge range isn't a
> superset, but rather an intersection with the existing
> mergeinfo *and* the ranges still to be merged are greater
> than the intersecting ranges, then the notification
> works:
>
> >svn merge -r4:6 %URL%/A/D merge_tests-1\A_COPY\D
> --- Merging r5 through r6 into 'merge_tests-1\A_COPY\D':
> U merge_tests-1\A_COPY\D\H\omega
>
> >svn pl -vR merge_tests-1
> Properties on 'merge_tests-1\A_COPY':
> svn:mergeinfo : /A:1
> Properties on 'merge_tests-1\A_COPY\D':
> svn:mergeinfo : /A/D:1,5-6
>
> >svn merge -r2:6 %URL%/A/D merge_tests-1\A_COPY\D
> ### r5-6 ALREADY PRESENT, SO THE
> ### NOTIFICATION ONLY REPORTS r3-4
> --- Merging r3 through r4 into 'merge_tests-1\A_COPY\D':
> U merge_tests-1\A_COPY\D\G\rho
> U merge_tests-1\A_COPY\D\H\psi
>
> >svn pl -vR merge_tests-1
> Properties on 'merge_tests-1\A_COPY':
> svn:mergeinfo : /A:1
> Properties on 'merge_tests-1\A_COPY\D':
> svn:mergeinfo : /A/D:1,3-6
>
> We still see the notification problem when the ranges
> intersect but the remaining ranges are less than the
> intersecting ranges:
>
> >svn merge -r2:4 %URL%/A/D merge_tests-1\A_COPY\D
> --- Merging r3 through r4 into 'merge_tests-1\A_COPY\D':
> U merge_tests-1\A_COPY\D\G\rho
> U merge_tests-1\A_COPY\D\H\psi
>
> >svn pl -vR merge_tests-1
> Properties on 'merge_tests-1\A_COPY':
> svn:mergeinfo : /A:1
> Properties on 'merge_tests-1\A_COPY\D':
> svn:mergeinfo : /A/D:1,3-4
>
> >svn merge -r2:6 %URL%/A/D merge_tests-1\A_COPY\D
> ### SHOULD BE 'r5 through r6'
> --- Merging r3 through r6 into 'merge_tests-1\A_COPY\D':
> U merge_tests-1\A_COPY\D\H\omega
>
> Possibly this will be useful in finding the problem.

Kamesh,

Attached is a quick patch I put together that addresses the failures I
described above and passes all the ra_local merge tests on Win32
(including 63). Please take a look, thanks,

Paul

[[[
Fix merge_tests.py 63 Failure.

* subversion/libsvn_client/merge.c
  (get_big_small_start_end_revs): New, replaces get_nearest_end_rev
  and get_farthest_end_rev.
  (get_nearest_end_rev, get_farthest_end_rev): Removed.
  (discover_and_merge_children): Use new get_big_small_start_end_revs
  to correctly calculate end *and* start revisions for subtree merge
  notifications.

* subversion/tests/cmdline/merge_tests.py
  (test_list): Remove Xfail from
  merge_fails_if_subtree_is_deleted_on_src.
]]]

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org