> -----Original Message-----
> From: Kamesh Jayachandran [mailto:kamesh_at_collab.net]
> Sent: Friday, January 11, 2008 3:04 PM
> To: Lieven Govaerts
> Cc: dev_at_subversion.tigris.org
> Subject: RE: issue-2897 branch work is complete
>
> Thanks Lieven.
>
> >Windows build:
>
> >FAIL: merge_tests.py 78: allow non-reflective changes from
> reflective
> >rev
> >FAIL: merge_tests.py 82: reflective merge on reincarnated target
>
> Cause of failure seems to be bit strange.
>
> Expected Properties: {'svn:mergeinfo':
> '/A/C:5-6,10\n/A/FB1:4-16\n/A/FB2:4-12\n'}
> Actual {'svn:mergeinfo':
> '/A/C:5-6,10\n/A/FB1:4-16\r\n/A/FB2:4-12\n'}
>
>
> Expected {'svn:mergeinfo': '/A/C:2-3,7,14\n/A/C1:11\n/A/FB:2-15\n'}
> Actual {'svn:mergeinfo': '/A/C:2-3,7,14\n/A/C1:11\r\n/A/FB:2-15\n'}
>
>
> See the in between merge source /A/FB1 and /A/C1 have CR character.
>
> Will investigate.
Hi Kamesh,
Those merge test failures are likely to be a bit tough for you to track
down without a Windows box so I took a look. The two merge test
failures occur on Windows because:
1) As you know, multiline svn:mergeinfo values are stored in UTF-8 with
LF line endings. So taking merge test 78 as an example, we have this
propval: "/A/C:5-6,10<LF>/A/FB1:4-16<LF>/A/FB2:4-12"
2) The test suite checks expected properties by calling svn proplist
--verbose which in svn/props.c:svn_cl__print_prop_hash() calls
svn_subst_detranslate_string() on the above propval converting it to
"/A/C:5-6,10<CR><LF>/A/FB1:4-16<CR><LF>/A/FB2:4-12". Then it calls
printf(" %s : %s\n", pname_stdout, propval->data) which actually
outputs the following to stdout:
Properties on 'merge_tests-78\A\C':<CR><LF>
svn:mergeinfo : /A/C:5-6,10<CR><CR><LF>
/A/FB1:4-16<CR><CR><LF>
/A/FB2:4-12<CR><LF>
This looks fine on the Win32 console as the <CR>s without <LF>s are
ignored.
3) The real problem is in tests/cmdline/svntest/tree.py:get_props() a
helper involved in building the actual disk tree for comparison to the
expected disk. In that method the eol marker of the first line of a
multiline prop value is stripped and replaced with <LF> ('\n'). But
then the subsequent lines are left as is as they are appended to the
'props' hash value. So if the mergeinfo property value has N lines,
line 2 through N-1 will end with <CR><CR><LF> ('\r\n'), which leads to
the failure you are seeing.
The only reason we never saw this on trunk was that none of the tests
create mergeinfo with values more than two lines long.
Anyhow I committed a fix to trunk in r28878. That will take care of
those two failures.
Paul
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe_at_subversion.tigris.org
For additional commands, e-mail: dev-help_at_subversion.tigris.org
Received on 2008-01-12 07:29:46 CET