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.
Now I'm getting confused. Let me try again:
There have been a couple of proposals for how to re-automate
deltification. Both proposals are essentially workarounds for the
fact that we have no portable way to fire off a thread to run the
deltification code. So the proposals are meant to achieve the same
effect by different means (the effect being that deltification gets
run in the background, after the commit is completed).
Proposal 1: Let's have the fs code itself invoke an independent
deltification binary, 'svndeltify' or whatever. The
post-commit hook wouldn't be involved; this would be
the fs code itself invoking the binary directly.
Proposal 2: Let's install a live post-commit hook at repository
creation time, that runs 'svnadmin deltify' in the
background. This would be the only uncommented bit in
the post-commit hook; the rest of the usual post-commit
template would be present but commented out as usual.
There have been objections to these proposals; some objections might
apply to both proposals, others only to one or the other. I feel that
the objections have gotten a bit confused now and that we aren't
keeping track of things carefully. Let's sort it out.
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.
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?
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? :-)
-Karl
---------------------------------------------------------------------
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:01:02 2003