Re: issue #137

On 9/1/06, Stefan Küng <tortoisesvn@gmail.com> wrote:
> Joseph Galbraith wrote:
> > If the tsvn:my-hook property was set to a/b/c.pl on
> > c:\wc, then we'd use c:\wc as the default path and
> > a/b/c.pl as the relative path, leading to:
> > c:\wc\a\b\c.pl as the hook-script.
> >
> > Would this work? Or am I majorly confused?
>
> Yes, of course that would work. But you know that we suggest to users to
> set the project properties on *all* folders in the working copy, because
> you can't be sure from which url they check out the working copy. For
> example, many translators don't have TSVN checked out from trunk, but
> only the /Languages folder.
> So as I said, you'd have to also set the property on that folder, which
> then has a different relative path (in your case "../a/b/c.pl").
> And that's what I meant with users complaining about setting those
> properties on all folders - you can't just set the property recursively
> like all other props, you must add them individually on each folder (now
> imagine a user with a working copy consisting of 10 levels of folders...).
Perhaps an interface option similar to "Set recursively" could be made
which automatically prepends necessary set of '../' in front of the
property for each level of recursion. This is probably a bad idea --
just brainstorming ;-)

> > Another alternative would be to use the global config
> > to give hook-scripts names:
> >
> > my-hook = c:\bin\xyzzy
> >
> > and then have the property refer to 'my-hook' instead
> > of c:\bin\xyzzy
> >
> > That does require every client to be configured-- but
> > then again, I'm not sure that is a bad thing. That
> > would definitely reduce the security concerns if the
> > hook had to be listed in the global config and what was
> > actually run was controlled there rather than in the
> > repository.
>
> I don't like the idea of a global config option which really is not
> global but per-project.
Still, I personally would very much prefer this option, for several reasons:

1) There are security concerns, which are well outlined in the
previous discussion, and which would prevent me from allowing absolute
paths and/or PATH environment variable for accessing executable hooks.

2) Absolute paths would not work for some, because not every
developer's machine has equivalent setup, so required hooks may end up
on different disks and paths. Also, there are cases when the hook
scripts are under version control, but in a separate
project/repository.

3) Hooks are not really 'per-project', but rather
'per-project-category' -- for example, pre-commit hook which checks
the log message on the client-side would be probably the same for a
few different projects, so it could have one config setting for them.

4) Finally, I think the best interface for the case when the hook is
run with undefined path is to display a dialog suggesting to select a
script to run or stop trying to run this hook. The second option can
be represented in config as
  hook-name=
line. An improvement for easier selection of scripts from working copy
could be made later.

-- 
Alexander S. Klenin
Insight Experts Ltd.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tortoisesvn.tigris.org
For additional commands, e-mail: dev-help@tortoisesvn.tigris.org