On Mon, Apr 23, 2012 at 6:11 AM, Branko Čibej <brane_at_apache.org> wrote:
> On 23.04.2012 00:00, Johan Corveleyn wrote:
>> On Wed, Apr 18, 2012 at 7:49 AM, Daniel Shahaf <danielsh_at_elego.de> wrote:
>>> Hyrum K Wright wrote on Tue, Apr 17, 2012 at 16:27:00 -0500:
>>>> On Tue, Apr 17, 2012 at 4:05 PM, Johan Corveleyn <jcorvel_at_gmail.com> wrote:
>>>>> On Tue, Apr 17, 2012 at 10:55 PM, Hyrum K Wright
>>>>> <hyrum.wright_at_wandisco.com> wrote:
>>>>>> On Tue, Apr 17, 2012 at 3:48 PM, Johan Corveleyn <jcorvel_at_gmail.com> wrote:
>>>>>>> On Tue, Apr 17, 2012 at 10:42 AM, Philip Martin
>>>>>>> <philip.martin_at_wandisco.com> wrote:
>>>>>>>> Johan Corveleyn <jcorvel_at_gmail.com> writes:
>>>>>>>>
>>>>>>>>> Apparently, the test is comparing the 'Repository Root' from the
>>>>>>>>> output of 'svn info' with the expected repository url. When I run 'svn
>>>>>>>>> info' manually on ...\svn-test-work\working_copies\basic_tests-29, I
>>>>>>>>> see the following:
>>>>>>>>>
>>>>>>>>> [[[
>>>>>>>>> Path: R:\test\subversion\tests\cmdline\svn-test-work\working_copies\basic_tests-29
>>>>>>>>> Working Copy Root Path:
>>>>>>>>> R:\test\subversion\tests\cmdline\svn-test-work\working_copies\basic_tests-29
>>>>>>>>> URL: file:///R%7C/test/subversion/tests/cmdline/svn-test-work/local_tmp/repos
>>>>>>>>> Repository Root:
>>>>>>>>> file:///R%7C/test/subversion/tests/cmdline/svn-test-work/local_tmp/repos
>>>>>>>>> ]]]
>>>>>>>>>
>>>>>>>>> So the '%7C' instead of ':' seems to be the problem (BTW, %7C is the
>>>>>>>>> pipe symbol, which seems quite strange here).
>>>>>>>>>
>>>>>>>>> When I use the same svn binary to do a new checkout of the same
>>>>>>>>> repository, over file://, I don't get this problem. So that indicates
>>>>>>>>> it's a problem with the test suite.
>>>>>>>> tests.log should show the exact command used to do the checkout. Is it
>>>>>>>> the same as the command you are running manually?
>> [ snip stuff about test output (loglevel) problems, for which Hyrum,
>> followed by Daniel suggested ... ]
>>
>>>> Run running individual tests, you can run them with
>>>> --set-log-level=INFO. I do not know how this translates to
>>>> win-tests.py, or if win-tests.py propagates that information to child
>>>> tests.
>>> Pass set_log_level=logging.DEBUG to TestHarness.__init__().
>> Thanks, that helped (level INFO sufficed)
>>
>> So, now I see that every single file:/// url in all of basic_tests.py
>> (and probably all my other tests as well) is used as
>>
>> "file:///R|/test/subversion/tests/cmdline..."
>>
>> Huh? And that even works? Yes, I just tried it manually on the commandline.
>>
>> I'm a bit stumped actually.
>
> Once again ... this is intentional for compatibility with Windows
> browsers. When the initial Windows port happened (some 12 years ago
> IIRC), all browsers on Windows would only accept file:// URLs in this
> format (Mozilla accepted the correct file:///X:/, too, but converted to
> the pipe form). I can only guess at the reason why someone decided that
> doing this was a good idea, but this is what Internet Explorer did,
> others followed suit, and Subversion adjusted its output accordingly --
> otherwise Windows users couldn't have copied svn output into a browser's
> address bar.
Ok, thanks for explaining. I got it more or less the first time, but
was just surprised.
> Both svn and the test suite on Windows still use this format for file://
> URLs, and IE still accepts it, although it displays local file paths as
> filenames, not URLs, and it also accepts the correct format with the colon.
>
> The test suite should account for this, so your failing test indicates a
> bug in the test suite. Are you running the 1.7 tests with a 1.6 build?
Nope, I'm only seeing this with a trunk build, with trunk tests. A 1.7
(or 1.6) build with tests from the same version runs fine, and the
test suite really uses "file:///R:/test" urls.
> Could be that in the course of 1.7 development, someone noticed that
> Windows browsers now conform to published standards with regard to URL
> syntax and decided to do remove the exception for file:// URLs on Windows.
During trunk (post-1.7) development ... maybe. I don't know. Something
changed on trunk after 1.7 branched, to make this happen.
However, I've now found another piece of the puzzle: I just upgraded
my Python to 2.7, and the problem is gone: test suite uses
"file:///R:/" urls. If I go back to using Python 2.6, it's using
"file:///R|/" urls, and this test fails (it's become basic_tests.py#30
in the meantime).
[[[
C:\research\svn\client_build\trunk2>python --version
Python 2.7.3
C:\research\svn\client_build\trunk2>runtest.bat -t basic_tests.py#30
Testing Debug configuration on local repository.
Running tests in basic_tests.py [1/1]...................................success
Summary of test results:
1 test PASSED
C:\research\svn\client_build\trunk2>set PATH=c:\research\Python26;%PATH%
C:\research\svn\client_build\trunk2>python --version
Python 2.6.2
C:\research\svn\client_build\trunk2>runtest.bat -t basic_tests.py#30
Testing Debug configuration on local repository.
Running tests in basic_tests.py [1/1]...................................FAILURE
At least one test FAILED, checking R:\test\tests.log
FAIL: basic_tests.py 30: check that repos root gets set on checkout
Summary of test results:
1 test FAILED
]]]
That may explain why the Windows buildbots aren't seeing this.
Fine by me. I'm using python 2.7.3 now. But still ... weird.
--
Johan
Received on 2012-06-05 02:01:02 CEST