The test in question (svnlook_tests.py 12 "test 'svnlook * -t'")
creates this pre-commit hook:
Which wraps the "real" Pyhthon hook:
fp = open(os.path.join(sys.argv, 'hooks.log'), 'wb')
def output_command(fp, cmd, opt):
command = [svnlook_bin, cmd, '-t', sys.argv, sys.argv] + opt
process = subprocess.Popen(command, stdin=subprocess.PIPE,
stdout=subprocess.PIPE, stderr=subprocess.PIPE, shell=False)
(output, errors) = process.communicate()
status = process.returncode
for (svnlook_cmd, svnlook_opt) in [('changed', ''), ('dirs-changed', '')]:
output_command(fp, svnlook_cmd, svnlook_opt.split(' '))
You'll notice that that the hook uses the svnlook binary from the
build we are testing.
This test passed for me over ra_local and ra_svn, but with ra_neon and
ra_serf, the 'hooks.log' file was empty after the test commits a
change. This causes the test to fail because it checks the contents
of 'hooks.log' after the commit and seeing nothing thinks that svnlook
So something wasn't working between Apache, the batch wrapper, the
python hook, and svnlook.exe.
Expanding a bit on what I said at the start: I built Apache myself
(2.2.10) and have the executable built by the InstallBin target
installed as a Windows Service. The test fails when going against
that. Starting httpd.exe manually from the command line, and using
the same conf file, it passes.
On Fri, Apr 9, 2010 at 12:15 AM, Greg Stein <gstein_at_gmail.com> wrote:
> What? I thought svnlook was purely a server-side tool. What does the
> RA layer have to do with it?
> On Thu, Apr 8, 2010 at 21:34, Paul Burba <ptburba_at_gmail.com> wrote:
>> As I mentioned in IRC earlier this week, svnlook_tests.py 12 was
>> failing for me on Windows over ra_neon and ra_serf (svnlook_tests.py
>> 11 on the 1.6.x branch).
>> The test failed when the python pre-commit hook failed to write the
>> output of 'svnlook -t' to a temporary file. Thing is, breaking a
>> debug mid-way through the tests' commit so the transaction file was
>> still present, and running svnlook from the command line worked fine.
>> Heck, even running the hook script from the command line worked.
>> At first I thought that only a release build of Apache was
>> susceptible; running the tests again a debug version of httpd.exe
>> worked fine. Somewhat belatedly I tried running against a manually
>> started release build of httpd.exe and damn if it didn't work too.
>> So it seems something is amiss with my Apache InstallBin target,
>> though what I'm not yet sure (and honestly won't be spending any more
>> time trying to figure out unless someone else has the same problem).
>> Anyhow, I mention all of this because for me it would have blocked
>> 1.6.11, but all is good now.
Received on 2010-04-09 15:17:05 CEST