Why can't I execute a client-side hook script when committing a switched path? Issue with %REPOROOT%?

[cw3...@cs.ship.edu]

We're having some issues on the Super User Stack Exchange right now with %REPOROOT%. A question was posted on Super User stack exchange

https://superuser.com/questions/1229204/why-cant-i-execute-a-client-side-hook-script-when-committing-a-switched-path?noredirect=1#comment1989124_1229204

Basically trying to run a pre-commit hook script, results in the file/directory not found error. The scripts themselves work fine, but this happens when you try and commit anything...where it should trigger the hook script but fails out with this error.

Even running exit 0 returns the same result.

Anyone know what the issue could be?

[Stefan]

Just tested with my own pre-commit hook script, and it works fine.

Did you switch the path where the hook script is located? Is the script still there in the switched path?

The hook-script-approve dialog shows you the command line to be executed - the path should be shown there as well. Does the script in that path exist?

Also, make sure you use quotes for all paths if the path contains spaces.

Stefan

[Carson Wood]

Thanks for the help, I may be misunderstanding but is %REPOROOT% going to be the svn repository for my team or is it going to be my local working copy? I haven't committed the batch files or hook script files yet, they've just been in my working directory as I don't want to mess up the entire teams work while working on this. I thought %REPOROOT% would be the trunk of my local working directory.

[Stefan]

On Monday, June 18, 2018 at 10:16:56 PM UTC+2, Carson Wood wrote:

Thanks for the help, I may be misunderstanding but is %REPOROOT% going to be the svn repository for my team or is it going to be my local working copy? I haven't committed the batch files or hook script files yet, they've just been in my working directory as I don't want to mess up the entire teams work while working on this. I thought %REPOROOT% would be the trunk of my local working directory.

No, %REPOROOT% refers to the path your working copy would be at if checked out from the root. But usually a checkout is done from /trunk.

e.g.

C:\dev\mywc checked out from /trunk

--> %REPOROOT% refers to C:\dev

--> %REPOROOT+% refers to C:\dev\mywc

Stefan

[Carson Wood]

Got it thanks. I have it working now if you, using TortSVN, right click SVN Commit on the root directory. However, if you go and try to commit and individual file within the directory I'm still getting the same error. 

I think this is due to the batch script being ran is assuming it's already in the root directory but if you are committing an individual file it will be in a different directory...and the batch file itself is doing a cd to run a grunt task

cd mow\client && grunt precommit

I guess is there a way to run the hook script from the root ? Do the hook scripts run from the root or do they run from the directory where the commit etc was called? 

[Carson Wood]

Ah nevermind that's a bash file issue solved with ||.

Thanks for all your help!

[asch...@gmail.com]

Let us assume a repository with the following structure:

• /hooks/
• script.bat    (this is a hook script containing `exit 0`)
  
• /branch/           (this is a branch of `/trunk`)
• file.txt
  
• /branches/
• /test/        (this is a branch of `/trunk` too)
• file.txt
  
• /trunk/
• file.txt
  

The working copy (WC) is checked out at D:\TEST\wc, but we have a sparse checkout so it looks like this:

• \hooks\
• script.bat
• \trunk\
• file.txt

Then set a property to the root: tsvn:startcommithook = start_commit_hook  %REPOROOT%/hooks/script.bat  true  show.

Now do the following in the WC:

• Commit a change to \trunk\file.txt; the hook approve/reject dialog shows the path D:\TEST\wc\hooks\script.bat and the script runs as expected upon approval.
• Switch the local path \trunk to the directory \branch in the repository.
• Commit a change to the switched \trunk\file.txt; the hook dialog again shows the path D:\TEST\wc\hooks\script.bat and the script runs normally.
• Switch the local path \trunk to the directory \branches\test in the repository.
• Commit a change to the switched \trunk\file.txt; the hook dialog now shows the path D:\TEST\hooks\script.bat (note the missing wc), the script does not run and an error message appears: The hook script returned an error.  The system cannot find the file specified. (the message is a bit misleading, because the script does actually not run, so it cannot return an error, also because its content is only exit 0).
  

So apparently, different depths in the repository directory hierarchy levels of normal (/trunk) and switched paths (/branches/test) seem to derogate proper expansion of the placeholder %REPOROOT%.

The behaviour does not change when applying the tsvn:startcommithook property recursively.

When I change %REPOROOT% to %REPOROOT+% and commit something to the not switched local path \trunk, not even the approve/reject dialog appears, which lets me suspect that the hook script is not running at all.

[Stefan]

thanks for the detailed reproduction recipe.

Fixed in r28670

[aschipfl]

You're welcome! And thank you very much for the fix!

Since %REPOROOT% should now work as expected, I have done some experiments with %REPOROOT+%. Here are the results, sticking to the aforementioned example, hence having the same repository and working copy structures:

Set and commit a property to the root: tsvn:startcommithook = start_commit_hook  %REPOROOT+%/hooks/script.bat  true  show.

Now do the following in the WC:

• Try to commit a change to \trunk\file.txt; the hook approve/reject dialog does not appear, so the script does not run and the Commit Dialog shows up immediately.

• Switch the local path \trunk to the directory \branch in the repository.

• Try to commit a change to \trunk\file.txt; the hook approve/reject dialog does not appear, so the script does not run and the Commit Dialog shows up immediately.

• Switch the local path \trunk to the directory \branches\test in the repository.

• Try to commit a change to \trunk\file.txt; the hook approve/reject dialog appears now and shows the path D:\TEST\wc\hooks\script.bat, the script runs as expected upon approval.
• Switch the local path \trunk back to the directory \trunk in the repository.
  

When following the same procedure with the property tsvn:startcommithook changed to start_commit_hook  %REPOROOT+%/script.bat  true  show (with top-level folder /hooks removed), the hook approve/reject dialog does never appear.

(Just to make sure I don't misunderstand %REPOROOT+%: this should find any missing top-level folders between the WC root and the remaining relative path, right?

So in the above example, specifying %REPOROOT+%/script.bat should be enough to find the script, correct?

Do I have to skip at least one top-level folder (like /hooks here), or should %REPOROOT+%/hooks/script.bat also find the script?)

N. B.: I found out as soon as %REPOROOT% or %REPOROOT+% is used to specify the hook script path, only forward slashes are accepted…

[Stefan]

On Wednesday, October 23, 2019 at 9:38:05 PM UTC+2, aschipfl wrote:

(Just to make sure I don't misunderstand %REPOROOT+%: this should find any missing top-level folders between the WC root and the remaining relative path, right?

So in the above example, specifying %REPOROOT+%/script.bat should be enough to find the script, correct?

Do I have to skip at least one top-level folder (like /hooks here), or should %REPOROOT+%/hooks/script.bat also find the script?)

Not quite: while the "+" might indicate that folders are inserted and tried, that's not how this works. Maybe I should have used *-" instead :)

What this does is to use the specified URL-part and try to append that to the current URL of the working copy root, then remove parts of that working copy URL and append the specified URL-part again until the script is found.

So for example if you specify

%REPOROOT+%/hooks/script.bat

and your working copy is at /trunk the script is found normally.

But if you switch your working copy to e.g. branches/mybranch, the "+" indicates that both branches/mybranch and branches are tried to find the script.