kfogel@collab.net wrote:
>Branko Čibej <brane@xbc.nu> 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.
>
>In http://subversion.tigris.org/servlets/ReadMsg?list=dev&msgNo=49201,
>you wrote:
>
> > 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.
[snip]
>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
>the difference.
>
>
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
objection.
>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[0] 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
the hooks.
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: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Tue Nov 25 22:59:05 2003