[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: RE: Re: Re: Run processes in background with post-commit hook on Windows

From: Adrien <hannibalbundy_at_gmail.com>
Date: Fri, 13 Jun 2008 16:55:53 +0200

Hi,

first of all thanks again for your contribution !

Indeed there is a solution in using windows cron, but I would like to have a
real-time solution to avoid too-much conflicts problem. And I've found it
with cygwin. So my post-commit.bat just call a post-commit.sh wherein I
close all the files descriptors when I run my background process.

Thanks for all

2008/6/13 Brian Erickson <erickson_at_bauercontrols.com>:

> Dumb work-around ....
>
> @echo off
> for /f "tokens=1,2,3* delims=: " %%I in ('time /t') do (
> set hour=%%I
> set min=%%J
> set ampm=%%K
> )
>
> set /a min+=1
> echo start time=%hour%:%min% %ampm%
> at %hour%:%min%%ampm% /interactive cmd /c d:\junk\pingdelay.bat
> Commit happens fine. One minute later, the background process
> start...There may be issues here with simultaineous commits and things but
> that's all I can think of for now...
>
> brian
>
> ------------------------------
> *From:* Brian Erickson [mailto:erickson_at_bauercontrols.com]
> *Sent:* Friday, June 13, 2008 7:02 AM
> *To:* Adrien
> *Cc:* Chris Lambrou; users_at_subversion.tigris.org
> *Subject:* RE: Re: Re: Run processes in background with post-commit hook
> on Windows
>
> I set up a sandbox repository here using the file:/// syntax and it was
> very easy to duplicate. I've no idea what Subversion is doing (or why) but
> I it's not a Windows issue. The start command starts a background task just
> like it's supposed to. The subversion client is waiting for it to finish
> and there doesn't appear to be a way to change that behavior. Sorry about
> that.
>
> Brian
>
> ------------------------------
> *From:* Adrien [mailto:hannibalbundy_at_gmail.com]
> *Sent:* Thursday, June 12, 2008 12:15 PM
> *To:* Brian Erickson
> *Cc:* Chris Lambrou; users_at_subversion.tigris.org
> *Subject:* Re: Re: Run processes in background with post-commit hook on
> Windows
>
> Yep, sorry for my english, i'm french and I've pain to explain the
> situation :-). But I see you're patient so I'm going to take full advantage
> !
>
> In fact, after the start command, the post-commit hook is totally ended but
> svn is still waiting for the end of the processes which have been launched
> by post-commit.bat to validate the commit. So, when a user commits his
> working copy, he has to wait the end of the background processes to re-work
> on it.
> About the file descriptors I don't really know, because it's a typical unix
> behaviour. I just know that on unix, svn keep contact with processes lauched
> by post-commit hooks by means of these processes file descriptors. So,
> always on unix, if you want to background jobs at post-commit you have to
> put ">> /dev/null 2>&1" as well as "&" behind your commands. That's the
> reason why I've tried to put "1>NUL 2>&1" as well as "start".
>
> And unfortunately the /l option does'nt change anything to my problem :-(.
>
> 2008/6/12 Brian Erickson <erickson_at_bauercontrols.com>:
>
>> I'm not quite sure I understand the problem...I'm not a Unix persion but
>> have been working with batch files forever (at least it feels like it...)
>>
>> Is it true that: when you use the start command, the post commit hook is
>> still waiting for the backgound process to finish? Furthermore the reason
>> for the wait is that Subversion file descriptors (which the background
>> process doesn't know or care about) are still open. Is that right?
>>
>> If that's so, the background command shell must have inherited them from
>> the commit hook. Have you tried using the /I option on the start command?
>>
>> I do know that the > and >> sytnax, in Windows, do not make anything run
>> in the background.
>>
>> Brian
>>
>> ------------------------------
>> *From:* Adrien [mailto:hannibalbundy_at_gmail.com]
>> *Sent:* Thursday, June 12, 2008 10:44 AM
>> *To:* Chris Lambrou
>> *Cc:* users_at_subversion.tigris.org
>> *Subject:* Re: Run processes in background with post-commit hook on
>> Windows
>>
>> Thanks for your reply, but actually I 've already used this command. My
>> batch file works fine when I run it mannually, but svn wait that all the
>> file descriptors the post-commit hook opens have been closed.
>>
>> In other words "start" is the equivalent of "&" in the unix world, and I'm
>> looking for the equivalent of ">> /dev/null 2>&1" or anyother trick wich
>> allows svn to validate commit once the post-commit hook is finished, and not
>> once all the processes ran by it are finished.
>>
>> This issue has already been discussed (see
>> http://subversion.tigris.org/servlets/ReadMsg?list=users&msgNo=53426 and
>> <http://svn.haxx.se/users/archive-2006-07/0421.shtml>
>> http://svn.haxx.se/users/archive-2006-07/0421.shtml) but no solution has
>> been proposed yet.
>>
>> 2008/6/12 Chris Lambrou <Chris.Lambrou_at_grantadesign.com>:
>>
>>> Adrien,
>>>
>>> Have a look at the *start* command. You can use it to spawn a separate
>>> process from a batch file, in a non-blocking manner. This allows your script
>>> to terminate, whilst leaving the spawned process running.
>>>
>>> Chris
>>>
>>> ------------------------------
>>> *From:* Adrien [mailto:hannibalbundy_at_gmail.com]
>>> *Sent:* 12 June 2008 13:35
>>> *To:* users_at_subversion.tigris.org
>>> *Subject:* Run processes in background with post-commit hook on Windows
>>>
>>> Hi,
>>>
>>> As said in the object, I've got some difficulties on Windows to run
>>> command in background with the post-commit hook. Indeed there is a solution
>>> on Unix with the redirection of stdout and stderr (in adding >> /dev/null
>>> 2>&1 at the command's end), but is there any equivalent on windows ? Because
>>> adding 1> NUL 2>&1 is unfortunately not enough.
>>>
>>> Thanks in advance.
>>>
>>
>>
>
Received on 2008-06-13 16:56:32 CEST

This is an archived mail posted to the Subversion Users mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.