[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: Updating a live website with a post-commit hook script

From: Bob Proulx <bob_at_proulx.com>
Date: 2006-06-30 18:55:10 CEST

Ryan Schmidt wrote:
> Bob Proulx wrote:
> >Lots of hard coded paths! If /usr/bin is not in path then there is a
> >problem. Hard coded paths to programs have always come back to bite
> >me. I recommend avoiding them.
> Um, since /usr/bin/svnlook is explicitly specified, /usr/bin does not
> need to be within the path. This is in fact the whole point, because
> in Subversion hooks, the path is not set, so you must use absolute
> paths or it won't work.

Uhm, they work for me. PATH *is* set for me when the hook scripts are
run. You can test this for yourself by save the $PATH in effect when
the hook script is run. In my case when run from my web server the
following PATH is set at the time the hooks are run:


That looks like the same PATH that is in effect for apache. I am sure
it is being inherited, just as desired.

> It might be better to define variables (or constants, depending on
> language) for the programs used, right at the top of the script, so
> that if you need to change the path, they're all in one place.

I still disagree with that type of implementation. It is very fragile
to operating system differents. One problem that it often leads to is
that it can become difficult to impossible to test scripts without
actually installing them. Or sometimes situations arise where people
think they are testing their changes off on the side but they are
actually running the installed copy. In both cases the problem is
that with hard coded paths it might be impossible to test without
actually installing them.

> The actual problem with the script above was that the svnlook command
> is not passed the $REV argument.

Very good for that analysis. I did not look at that script that
closely. I just liked the concept of only updating the files that
changed instead of everything.


To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Fri Jun 30 18:56:39 2006

This is an archived mail posted to the Subversion Users mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.