Program to start long running hooks in Windows for Subversion >= 1.3

[si <ss...@gmail.com>]

Greetings,

As I wasn't able to find a simple work-around for the issue of Subversion post-
commit hooks not immediately returning to clients after a commit on Windows
for svn >= 1.3 (see http://subversion.tigris.org/issues/show_bug.cgi?id=2560)
I ended up writing a simple app which solves the problem for me. Others running
.net might also find it useful, so i've attached the source and exe,
along with a
nant build file.

Caveats:
- Only tested on .net 2.0, but should work on .net 1.1
- Ensure program has full path and filename, including appropriate extensions
- If you run svnserve as per Microsoft recommendations as Local Service
or Network Service instead of Local System, ensure process has rights to
execute HookStart.exe.

I've also updated Subnant (my Subversion admin toolkit), if you use this and
want the fix, update from trunk and call 'subnant install', this will create a
hookstart wrapper in the same location as subnant wrapper and compile
HookStart.exe for you. Then update your hooks and Subnant default hooks
with the new wrapper, see hooks/post-commit.bat.example

Feedback welcome.

peace
si

p.s. I've no doubt someone will now come along and show me how to spawn a
process via dos with closed streams which solves this problem...good for you :)

Re: Program to start long running hooks in Windows for Subversion >= 1.3

["Matthew S. Moore" <mm...@asf.alaska.edu>]

si wrote:
 > Hi Ryan,
 >
 >> That bug says it is "resolved" and "works for me."
 >
 > Correct, apparently it works fine on Linux, which seemed to
 > be the o/s used by the person who replied to the bug report.
 >
 >> Are you saying it still does not work?
 >
 > Perhaps a better way of saying it is I've yet to see a way to
 > spawn processes in Windows using standard commands
 > whilst ensuring the stdout and stderr streams where closed.
 >
 > In a nutshell, svn < 1.3.0 running "start /b <cmd>" worked in
 > spawning post commit hooks, but in svn >= 1.3.0 it doesn't.
 >
 > The difference seems to be with Linux you just have to place
 > an ampersand on the end of a command to spawn it, whereas
 > in Windows you have to use another command, so the redirection
 > rules may be changed (not sure), but I tried many combinations
 > and couldn't get it any to work.
 >
 >> Does the bug need to be reopened?
 >
 > If someone can demonstrate how to do it in Windows,
 > then no, otherwise perhaps it should be. If it does get
 > resolved, it's probably a faq worthy entry.

   I have been having similar problems running under Cygwin on a Win2000 system. 
  I wrote my post-commit scripts to send email and to perform per-commit backups 
(incremental, hot, and full depending on the rev number).  They are perl scripts 
called with & at the end from inside the post-commit shell script.  This has 
worked just fine for a long time.

   Then I upgraded to v1.3.0 using the current Cygwin package.  I eventually 
noticed that the commits were not returning immediately for the full/hot backup 
revs.  I did a little research and found references to the bug you mention 
below.  So, I used Subversion source package for Cygwin with the v1.3.2 source 
and built my own updated Cygwin patch.  It installed fine and seems to work for 
the most part.

   However, it was mentioned in the bug report that with the fixed post-commit 
behavior, you must redirect stout/stderr.  When I do this:

backup.pl ... &>/dev/null &

   The commit does seem to come back OK, except now my email and backup scripts 
don't produce any output.  Both scripts also redirect stdout/stderr to log files 
  which don't get written.  If I take off the redirection to /dev/null above, 
then the scripts produce output correctly, but don't background and the commit 
on the client side has to wait for the scripts to finish.

   Is this just a Windows(/Cygwin) problem, or has anyone seen this on Linux 
systems, too?

   Thanks,

Matthew


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org

Re: Program to start long running hooks in Windows for Subversion >= 1.3

[si <ss...@gmail.com>]

Hi Ryan,

> That bug says it is "resolved" and "works for me."

Correct, apparently it works fine on Linux, which seemed to
be the o/s used by the person who replied to the bug report.

> Are you saying it still does not work?

Perhaps a better way of saying it is I've yet to see a way to
spawn processes in Windows using standard commands
whilst ensuring the stdout and stderr streams where closed.

In a nutshell, svn < 1.3.0 running "start /b <cmd>" worked in
spawning post commit hooks, but in svn >= 1.3.0 it doesn't.

The difference seems to be with Linux you just have to place
an ampersand on the end of a command to spawn it, whereas
in Windows you have to use another command, so the redirection
rules may be changed (not sure), but I tried many combinations
and couldn't get it any to work.

There is probably another way to achieve this using dos,
but I couldn't find it, so rolled my own solution.

> Does the bug need to be reopened?

If someone can demonstrate how to do it in Windows,
then no, otherwise perhaps it should be. If it does get
resolved, it's probably a faq worthy entry.

> Are you using Subversion 1.3.2?

Yes

peace
si

p.s. There do seem to be differences between the Windows
and Linux implementation of Subversion which are not detailed
in the documentation. For example, environment variables are
retained in hooks in Windows, but not in Linux.

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org

Re: Program to start long running hooks in Windows for Subversion >= 1.3

[Ryan Schmidt <su...@ryandesign.com>]

On Jul 11, 2006, at 05:14, si wrote:

> As I wasn't able to find a simple work-around for the issue of  
> Subversion post-
> commit hooks not immediately returning to clients after a commit on  
> Windows
> for svn >= 1.3 (see http://subversion.tigris.org/issues/ 
> show_bug.cgi?id=2560)
> I ended up writing a simple app which solves the problem for me.

That bug says it is "resolved" and "works for me." Are you saying it  
still does not work? Does the bug need to be reopened? Are you using  
Subversion 1.3.2?


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org