I have a set of server-side Pre- and Post-Commit hooks that would make tracking changes easier for us (VisualSVN on a Windows server, if that matters):
The Pre-Commit exports the users files to the server if they are of a specific type (binary files), and then uses a program to export these to a text-based format which any text-editor can view.
The Post-Commit should then SVN-import these files to the same repository and same folder as the original file was committed to, as now-trackable .exp-files.
My problem lies in the Post-Commit: It seems that running an Import (later replaced by 'svnmucc put') does not work while the previous commit is active (the users commit seemingly does not complete fully before this script is finished). The script therefore gets stuck here, no error or message details, and does not complete the Post-Commit.
This is the problematic line (if I remove Echo, the commit stops):
Echo svnmucc put %LineName% %Address% -F comment%TXN%.txt --non-interactive --no-auth-cache>Command.txt
This is the output in 'Command.txt' which successfully runs if initiated afterwards:
svnmucc put Test2.exp https://10.49.1.52/svn/PlcLibraries/TestFolder/Lib/Test2.exp -F comment79-6m.txt --non-interactive --no-auth-cache
The problem here seems to be that the folder is locked, or commits are otherwise blocked, until the original commit is finished, which means that this command waits for the original commit to quit. If I could somehow either make the post-commit unlock the folder, or force the svnmucc to run, this would solve my problem.
My question is therefore: is there a way to make this work? For us, the best-case scenario would be that SVN somehow manages this after the commit is successful, but it seems running any script in Post-Commit makes the SVN-client wait for these scripts to finish before completing fully.
Another reason why server-side commit-scripts would be preferrable, is because the whole export-to-readable-format-operation happens on the server. The .exp-file is therefore stored on the server, not the client. A possibility could be to add this file to the original commit, but I've never seen anyone explain how.
It is hard to determine the root cause of this behavior without looking at the pre- and post- commit hook code that you run. However, it seems that you are running into recursion problems because:
I guess that your hook script runs
svn importor other operation that should makes a new commit. This operation will trigger your commit hooks again resulting into the loop.What SVN client do your users use? Is it TortoiseSVN? Do they use any other clients?
I am asking about TortoiseSVN because it supports client-side hook scripts and it is possible that performing this export / conversion to
*.expformat would be better to do on the client side.Feel free to expand your question with more details - more information will help better understand your case and requirements.