>Branko Čibej <firstname.lastname@example.org> writes:
>>I don't like this at all. First of all, making .bat files universally
>>work as hook programs on Windows hasn't happened yet, and could be a bit
>>of a problem. But I'm much more worried about the idea of hard-coding
>>program paths at compile time. Whilst this may be standard (if broken!)
>>practice on Unix, it will _not_ work on Windows because there's no such
>>thing as a standard install location.
>Hmmm, wait a minute.
> > Why not? Anyway, we don't have to put this into "svnadmin", we
> > can create a custom binary (e.g., svndeltify) and simply demand
> > that it _is_ installed in a place where Apache, svnserve,
> > etc. can find it. It's no more complicated than installing
> > mod_dav_svn.so, and it's a _lot_ easier than making default hook
> > scripts or cron scripts that work on all platforms.
There's no contradiction.
>The first objections applies to both proposals, and it is:
> "It's bad for Subversion to invoke another executable found at some
> hardcoded path."
>Brane, I may have misunderstood what you were saying, but it appears
>that you considered this objection valid in one circumstance, yet
>invalid in another (see quoted mail above), and I can't figure out why
No. In the first case, I'm arguing against using a hardcoded path. In
the second, I'm talking about putting the binary in a place where the
server can find it, which does _not_ imply using a hardcoded path.
>Another objection, applying to Proposal 2 only, is:
> "It's difficult to install a live post-commit script automatically,
> such that the system will reliably run it."
>Uh, okay. I don't really know enough to evaluate this objection. I
>know we can do this portably on Unix -- just use "#!/bin/sh" and make
>sure the script is executable, and everything will be fine. I had
>thought that .BAT files were equally reliable on all Windows systems,
>but apparently that's not the case?
An installed batch file must use an absolute, hardcoded path. That's my
>If it's true that installing a live post-commit is problematic on
>Windows, then I'm fine with Proposal 1, as described below by Brane:
>>But that's irrelevant. We can make a small hook _program_ that's called
>>the same way on all platforms and install that. Take the code from
>>"svnadmin deltify" and move it to "svndeltify", and install that in the
>>repository (using a symlink on Unix, for all I care). Locating this
>>program at "svnadmin create" time is no problem at all -- just require
>>it to be installed in the same directory as svnadmin. Then add a bit of
>>code to the hooks launcher that runs this in the background -- using
>>portable APR calls -- at the same time as the post-commit hook. Then, if
>>the admin prefers to deltify in a cron job, they just remove the
>>svndeltify instance from the hooks directory.
>We just have to sort out this hardcoded-path-to-a-program
>question... So, is there really a problem here? :-)
We don't need hardcoded paths to a program if we have argv and, for
mod_dav_svn, the ServerRoot directive.
So my suggestion is:
* Don't use a hardcoded path.
* Do use a dedicated program that's invoked by the repos layer, like
There are two ways to do this:
* Copy (or symlink on Unix) this dedicated binary into the hooks
directory of each repository. This way only svnadmin has to know
where to find it. Or,
* Let the server (svnserve, mod_dav_svn, ra_local) tell the repos
layer where to find this binary.
I think the first solution is better, because it localizes the
dependency on "svnadmin create".
Brane Čibej <brane_at_xbc.nu> http://www.xbc.nu/brane/
To unsubscribe, e-mail: email@example.com
For additional commands, e-mail: firstname.lastname@example.org
Received on Tue Nov 25 22:59:05 2003