Alexander Klenin wrote:
> 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.
I'd been talked out of this until I saw #4; it has a certain
amount of elegance, especially since if we use this mechanism
to configure the scripts we could associate make the binding
repository specific by storing the UUID with it (and it
could happen transparently with the user none the wiser.)
I do still like the idea of allowing repository root relative
paths as well, with a ask-permission model.
Thanks,
Joseph
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tortoisesvn.tigris.org
For additional commands, e-mail: dev-help@tortoisesvn.tigris.org
Received on Fri Sep 1 02:21:59 2006