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

Re: permanent solution for deltification problem (issue #1601)

From: Branko Čibej <brane_at_xbc.nu>
Date: 2003-11-25 22:56:30 CET

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.

>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

>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

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

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