> -----Original Message-----
> From: Paul Burba [mailto:pburba collab.net]
> Sent: Thursday, October 04, 2007 12:32 PM
> To: devsubversion.tigris.org; kameshjtigris.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; devsubversion.tigris.org;
kameshjtigris.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/bui
lds/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-workworking_copiesmerge_tests-63A_copyDgamma'
> > 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 'SOMEPATH':")
> <_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-1A
> 1 1 jrandom
merge_tests-1AB
> 1 1 jrandom
merge_tests-1ABlambda
> 1 1 jrandom
merge_tests-1ABE
> 1 1 jrandom
merge_tests-1ABEalpha
> 5 5 jrandom
merge_tests-1ABEbeta
> 1 1 jrandom
merge_tests-1ABF
> 1 1 jrandom
merge_tests-1Amu
> 1 1 jrandom
merge_tests-1AC
> 1 1 jrandom
merge_tests-1AD
> 1 1 jrandom
merge_tests-1ADgamma
> 1 1 jrandom
merge_tests-1ADG
> 1 1 jrandom
merge_tests-1ADGpi
> 4 4 jrandom
merge_tests-1ADGrho
> 1 1 jrandom
merge_tests-1ADGtau
> 1 1 jrandom
merge_tests-1ADH
> 1 1 jrandom
merge_tests-1ADHchi
> 6 6 jrandom
merge_tests-1ADHomega
> 3 3 jrandom
merge_tests-1ADHpsi
> 2 2 jrandom
merge_tests-1A_COPY
> 2 2 jrandom
merge_tests-1A_COPYB
> 2 2 jrandom
> merge_tests-1A_COPYBlambda
> 2 2 jrandom
merge_tests-1A_COPYBE
> 2 2 jrandom
> merge_tests-1A_COPYBEalpha
> 2 2 jrandom
> merge_tests-1A_COPYBEbeta
> 2 2 jrandom
merge_tests-1A_COPYBF
> 2 2 jrandom
merge_tests-1A_COPYmu
> 2 2 jrandom
merge_tests-1A_COPYC
> 2 2 jrandom
merge_tests-1A_COPYD
> 2 2 jrandom
merge_tests-1A_COPYDgamma
> 2 2 jrandom
merge_tests-1A_COPYDG
> 2 2 jrandom
merge_tests-1A_COPYDGpi
> 2 2 jrandom
merge_tests-1A_COPYDGrho
> 2 2 jrandom
merge_tests-1A_COPYDGtau
> 2 2 jrandom
merge_tests-1A_COPYDH
> 2 2 jrandom
merge_tests-1A_COPYDHchi
> 2 2 jrandom
> merge_tests-1A_COPYDHomega
> 2 2 jrandom
merge_tests-1A_COPYDHpsi
> 1 1 jrandom
merge_tests-1iota
>
> >svn pl -vR merge_tests-1
> Properties on 'merge_tests-1A_COPY':
> svn:mergeinfo : /A:1
>
> ### WE EXPECT AND SEE NOTIFICATION FOR r4-5
INCLUSIVE...
> >svn merge -r3:5 %URL%/A/D merge_tests-1A_COPYD
> --- Merging r4 through r5 into
'merge_tests-1A_COPYD':
> U merge_tests-1A_COPYDGrho
>
> >svn pl -vR merge_tests-1
> Properties on 'merge_tests-1A_COPY':
> svn:mergeinfo : /A:1
> Properties on 'merge_tests-1A_COPYD':
> 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-1A_COPYD
> ### THIS LOOKS FINE, JUST r2
> --- Merging r3 into 'merge_tests-1A_COPYD':
> U merge_tests-1A_COPYDHpsi
> ### BUT SHOULDN'T THIS BE *JUST* r6 IN THE
NOTIFICATION?
> --- Merging r4 through r6 into
'merge_tests-1A_COPYD':
> U merge_tests-1A_COPYDHomega
>
> ### AT LEAST THE MERGEINFO IS RIGHT 
> >svn pl -vR merge_tests-1
> Properties on 'merge_tests-1A_COPY':
> svn:mergeinfo : /A:1
> Properties on 'merge_tests-1A_COPYD':
> 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-1A_COPYD
> --- Merging r5 through r6 into
'merge_tests-1A_COPYD':
> U merge_tests-1A_COPYDHomega
>
> >svn pl -vR merge_tests-1
> Properties on 'merge_tests-1A_COPY':
> svn:mergeinfo : /A:1
> Properties on 'merge_tests-1A_COPYD':
> svn:mergeinfo : /A/D:1,5-6
>
> >svn merge -r2:6 %URL%/A/D merge_tests-1A_COPYD
> ### r5-6 ALREADY PRESENT, SO THE
> ### NOTIFICATION ONLY REPORTS r3-4
> --- Merging r3 through r4 into
'merge_tests-1A_COPYD':
> U merge_tests-1A_COPYDGrho
> U merge_tests-1A_COPYDHpsi
>
> >svn pl -vR merge_tests-1
> Properties on 'merge_tests-1A_COPY':
> svn:mergeinfo : /A:1
> Properties on 'merge_tests-1A_COPYD':
> 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-1A_COPYD
> --- Merging r3 through r4 into
'merge_tests-1A_COPYD':
> U merge_tests-1A_COPYDGrho
> U merge_tests-1A_COPYDHpsi
>
> >svn pl -vR merge_tests-1
> Properties on 'merge_tests-1A_COPY':
> svn:mergeinfo : /A:1
> Properties on 'merge_tests-1A_COPYD':
> svn:mergeinfo : /A/D:1,3-4
>
> >svn merge -r2:6 %URL%/A/D merge_tests-1A_COPYD
> ### SHOULD BE 'r5 through r6'
> --- Merging r3 through r6 into
'merge_tests-1A_COPYD':
> U merge_tests-1A_COPYDHomega
>
> 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-unsubscribesubversion.tigris.org
For additional commands, e-mail: dev-helpsubversion.tigris.org
|
