[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: <kfogel_at_collab.net>
Date: 2003-11-25 22:22:32 CET

Branko Čibej <brane@xbc.nu> writes:
> 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.

Hmmm. A hook file can use paths relative to the $REPOS directory,
since that's one of the hook parameters...

> 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,

Yup; see above.

I'm not saying the hook solution is necessarily better than the
fs-driven solution. I'm just saying that either they both need a
hardcoded path, or neither does.


To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Tue Nov 25 23:09:26 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.