You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by Garrett Rooney <ro...@electricjellyfish.net> on 2005/12/13 19:05:30 UTC

Re: svn trunk r17762: FAIL (win32 ra_svn fsfs)

On 12/13/05, svn-builder@shadyvale.net <sv...@shadyvale.net> wrote:

> At least one test FAILED, checking D:\tests-svn\svn-tests.log
> FAIL:  commit_tests.py 34: post commit hook failure case testing
> FAIL:  prop_tests.py 11: set, get, and delete a revprop change
> FAIL:  log_tests.py 10: svn log --xml must not print empty date elements
> FAIL:  trans_tests.py 8: keyword expanded on cat
> At least one test was SKIPPED, checking D:\tests-svn\svn-tests.log

Ok, I'm confused.  This says that these tests failed, but they show up
as passed in the attached test.log.gz file.  Is this machine not
attaching the correct test output, or is it looking at the wrong
output when it looks for failures, or what?  Perhaps fallout from the
subversion/tests/svn -> subversion/tests/cmdline thing?

-garrett

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org


Re: svn trunk r17762: FAIL (win32 ra_svn fsfs)

Posted by Philip Martin <ph...@codematters.co.uk>.
Garrett Rooney <ro...@electricjellyfish.net> writes:

> On 12/14/05, D.J. Heap <dj...@gmail.com> wrote:
>>
>> After taking a look, all the failures are due to the relative paths in
>> the generated hook files.  Are hooks supposed to be run with a
>> specific working directory or should they not expect to have a known
>> working directory?
>
> I'm not really sure.  Personally I always try to use absolute paths in
> them though, and I don't recall any code that sets up a particular
> working directory before running them.

hooks.c:run_hook_cmd() passes "." to io.c:svn_io_start_cmd() where it
gets used to set the working directory.  I guess that means the hooks
get the working directory from the server process rather than the
repository.

-- 
Philip Martin

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org

Re: svn trunk r17762: FAIL (win32 ra_svn fsfs)

Posted by Garrett Rooney <ro...@electricjellyfish.net>.
On 12/14/05, D.J. Heap <dj...@gmail.com> wrote:
> >
> > The first failure (hook) is due to a relative path in the hook -- the
> > svnserve process is not being started with a working directory of
> > where the hook is assuming it will be, I think.  I'm not sure if the
> > hook should have an absolute path or if the svnserve process should be
> > started with a specific working directory?  I don't think the tests
> > used to require that, but I'm not sure.
> >
> > I haven't looked at the other failures yet, but they may be related.
> >
>
>
> After taking a look, all the failures are due to the relative paths in
> the generated hook files.  Are hooks supposed to be run with a
> specific working directory or should they not expect to have a known
> working directory?

I'm not really sure.  Personally I always try to use absolute paths in
them though, and I don't recall any code that sets up a particular
working directory before running them.

-garrett

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org


Re: svn trunk r17762: FAIL (win32 ra_svn fsfs)

Posted by "D.J. Heap" <dj...@gmail.com>.
>
> The first failure (hook) is due to a relative path in the hook -- the
> svnserve process is not being started with a working directory of
> where the hook is assuming it will be, I think.  I'm not sure if the
> hook should have an absolute path or if the svnserve process should be
> started with a specific working directory?  I don't think the tests
> used to require that, but I'm not sure.
>
> I haven't looked at the other failures yet, but they may be related.
>


After taking a look, all the failures are due to the relative paths in
the generated hook files.  Are hooks supposed to be run with a
specific working directory or should they not expect to have a known
working directory?

DJ

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org


Re: svn trunk r17762: FAIL (win32 ra_svn fsfs)

Posted by "D.J. Heap" <dj...@gmail.com>.
On 12/13/05, Garrett Rooney <ro...@electricjellyfish.net> wrote:
> On 12/13/05, svn-builder@shadyvale.net <sv...@shadyvale.net> wrote:
>
> > At least one test FAILED, checking D:\tests-svn\svn-tests.log
> > FAIL:  commit_tests.py 34: post commit hook failure case testing
> > FAIL:  prop_tests.py 11: set, get, and delete a revprop change
> > FAIL:  log_tests.py 10: svn log --xml must not print empty date elements
> > FAIL:  trans_tests.py 8: keyword expanded on cat
> > At least one test was SKIPPED, checking D:\tests-svn\svn-tests.log
>
> Ok, I'm confused.  This says that these tests failed, but they show up
> as passed in the attached test.log.gz file.  Is this machine not
> attaching the correct test output, or is it looking at the wrong
> output when it looks for failures, or what?  Perhaps fallout from the
> subversion/tests/svn -> subversion/tests/cmdline thing?


Yes, the wrong test log was attached...my fault.  That should be fixed now.

The first failure (hook) is due to a relative path in the hook -- the
svnserve process is not being started with a working directory of
where the hook is assuming it will be, I think.  I'm not sure if the
hook should have an absolute path or if the svnserve process should be
started with a specific working directory?  I don't think the tests
used to require that, but I'm not sure.

I haven't looked at the other failures yet, but they may be related.

DJ

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org