deploiment of client side hook scripts

[lorenz]

While fiddling with my pre-lock script I began thinking about how to
deploy it to all my colleges.

I know about the tsvn:...hook properties, but they require that the
hook script is part auf the working copy.
That means, I can't just set these property on the root of the
repository, because then WCs checked out from subfolders wouldn't
contain the scripts.

I remember darkly having researched this topic in the past.
I think the reason tsvn does not allow only scripts that are part of
the WC was for security reasons.
I even think I posted a question back then.

But I don't seem to be able to find this information and/or post again
though.

Can anyone please point me in the approximate direction?
--

Lorenz

[Stefan]

first of all: if the script isn't in the WC then what path are you going to specify? Meaning to make this work you have to make sure that all users/developers have the script in the very same path. That's not really practical and will break easily.

And if it's not part of the WC, then you could potentially execute something you don't really want: just imagine you're checking out an opensource project which has hook scripts defined with absolute paths. Now you do something to trigger one of those scrips, but in your case you have a completely different script in that absolute path...

[lorenz]

I was envisioning something managed by TSVN.

(A) WC(s) in %AppData%\Roaming\TortoiseSVN for instance where TSVN
would check out the required hook scripts (one (sparse) WC per hook
URL, one WC using file-externals, ...).
Perhaps with Settings/Properties to control how often to check for
updates.

For new and updated hook scripts TSVN would then inform the user and
ask for permission to use the new/updated script (the dialog could
even provide a button to view a diff).

I'm aware, that is not something easy to design and implement, and
surely not on one afternoon 8-)
--

Lorenz

[Daniel Sahlberg]

I'm thinking along the same lines. The design would be similar to the way you can configure Subversion's password-db/authz-db with a ^/filename to use a file in the repository.

The security implications would be more or less the same as using a script in the WC. TSVN already store a hash of an "approved script" that exists in the WC and when the script changes the user will be prompted to approve the new script. Supporting a ^.../ path just means checking out a hidden WC somewhere (%appdata%?) and keeping it updated.

This is a reasonable use case for me and I could probably look the code, but I would like to ask for Stefan's confirmation that he would consider merging this in the end before doing a lot of work.

For the time being, I'm setting up all our client computers to checkout the script to C:\XXXXX\ and doing an SVN UP using Task Scheduler. That will more or less accomplish the same thing but it would be handy if TSVN could manage it automatically.

[Stefan]

On Friday, March 12, 2021 at 12:11:03 PM UTC+1 daniel.l...@gmail.com wrote:

fredag 12 februari 2021 kl. 09:27:25 UTC+1 skrev lorenznl:

I was envisioning something managed by TSVN.

(A) WC(s) in %AppData%\Roaming\TortoiseSVN for instance where TSVN
would check out the required hook scripts (one (sparse) WC per hook
URL, one WC using file-externals, ...).
Perhaps with Settings/Properties to control how often to check for
updates.

For new and updated hook scripts TSVN would then inform the user and
ask for permission to use the new/updated script (the dialog could
even provide a button to view a diff).

I'm aware, that is not something easy to design and implement, and
surely not on one afternoon 8-)

Ok, so that means you have a way to copy files to every users appdata directory.

If you can do that, you can also add registry entries for each user.

And if you can do that, you can configure the hooks that way.

I suggest you read about group policies and use them on your domain control server.

Much easier to handle than what you're trying to do now.

I'm thinking along the same lines. The design would be similar to the way you can configure Subversion's password-db/authz-db with a ^/filename to use a file in the repository.

The security implications would be more or less the same as using a script in the WC. TSVN already store a hash of an "approved script" that exists in the WC and when the script changes the user will be prompted to approve the new script. Supporting a ^.../ path just means checking out a hidden WC somewhere (%appdata%?) and keeping it updated.

how would TSVN keep that updated? Every time the hook script should run? You'll make your users very angry because of that slowdown...

 

This is a reasonable use case for me and I could probably look the code, but I would like to ask for Stefan's confirmation that he would consider merging this in the end before doing a lot of work.

I don't think I would want to merge something like this. Sorry.

 

For the time being, I'm setting up all our client computers to checkout the script to C:\XXXXX\ and doing an SVN UP using Task Scheduler. That will more or less accomplish the same thing but it would be handy if TSVN could manage it automatically.

and you could use a group policy on the domain controller to set up the hook script in TSVN as well as your task scheduler entry.

 

[Daniel Sahlberg]

fredag 12 mars 2021 kl. 17:18:42 UTC+1 skrev Stefan:

On Friday, March 12, 2021 at 12:11:03 PM UTC+1 daniel.l...@gmail.com wrote:

fredag 12 februari 2021 kl. 09:27:25 UTC+1 skrev lorenznl:

I was envisioning something managed by TSVN.

(A) WC(s) in %AppData%\Roaming\TortoiseSVN for instance where TSVN
would check out the required hook scripts (one (sparse) WC per hook
URL, one WC using file-externals, ...).
Perhaps with Settings/Properties to control how often to check for
updates.

For new and updated hook scripts TSVN would then inform the user and
ask for permission to use the new/updated script (the dialog could
even provide a button to view a diff).

I'm aware, that is not something easy to design and implement, and
surely not on one afternoon 8-)

Ok, so that means you have a way to copy files to every users appdata directory.

If you can do that, you can also add registry entries for each user.

And if you can do that, you can configure the hooks that way.

I suggest you read about group policies and use them on your domain control server.

Much easier to handle than what you're trying to do now.

Not all computers are part of a domain.

 

I'm thinking along the same lines. The design would be similar to the way you can configure Subversion's password-db/authz-db with a ^/filename to use a file in the repository.

The security implications would be more or less the same as using a script in the WC. TSVN already store a hash of an "approved script" that exists in the WC and when the script changes the user will be prompted to approve the new script. Supporting a ^.../ path just means checking out a hidden WC somewhere (%appdata%?) and keeping it updated.

how would TSVN keep that updated? Every time the hook script should run? You'll make your users very angry because of that slowdown...

That is a good point.  Possibly updating only when the main WC is updated. Still a slowdown but far less often, depending on how often you update. The slowdown obviously only occur if there is a hook script configured using a ^.../ path.

This is a reasonable use case for me and I could probably look the code, but I would like to ask for Stefan's confirmation that he would consider merging this in the end before doing a lot of work.

I don't think I would want to merge something like this. Sorry.

If you reconsider, let's pick up the discussion again.