Eric Gillespie wrote:
> lgo@tigris.org writes:
>
>> Follow up r26920, fix update_tests.py 38: on Windows, using the
>> apr calls svn can only execute external applications that are
>> considered executable (.bat, .exe etc). So when we want svn to
>> call .py scripts we have to use the same trick as for the hook
>> scripts, ie. add a batch file to wrap the .py file.
>
> Huh. I only added a new use in update_tests. How did the rest
> of these pass? Have these tests been subtly broken on Windows
> all this time?
>
> commit_tests.py:2271: svntest.main.use_editor('append_foo')
> prop_tests.py:71: svntest.main.use_editor('foo_to_bar')
> prop_tests.py:91: svntest.main.use_editor('identity')
> prop_tests.py:1190: svntest.main.use_editor('foo_to_bar')
> prop_tests.py:1210: svntest.main.use_editor('identity')
>
No they haven't.
The problem lies in the --accept=launch test. For all other testcases in
update_accept_conflicts and for the tests you mention above, Subversion
is only calling the svneditor.py script once through a system call.
Example: svn_cl__edit_file_externally in svn/util.c.
For the --accept=launch test, subversion is also launching a separate
executable, not through a system call, but through an apr call in
svn_cl__merge_file_externally in svn/util.c.
The system call starts up a shell, so on Windows it can run whatever
scripts you have as executable on your system.
I don't know why the other call uses the apr function, I assume because
it needs to know the return value of the script.
Lieven
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Sun Oct 7 08:08:27 2007