On Thursday 02 December 2004 23:03, Tom Rawson wrote:
> That behavior is because it's a DOS prompt, not because it's Notepad.
> The issue is in the calling program -- in this case svn. The type of
> app and the API call used to start it will determine what happens. I
> believe the rules go like this though my memory is slightly rusty:
> From a Win32 console app (that's what svn.exe is on Windows) ...
>
> * If you use ShellExecute to start another console app or a DOS
> app that app runs in the same session and the API blocks (does not
> return) until the app exits.
>
> * If you use ShellExecute to start a Windows app like (Notepad)
> that app runs separately, and the API does not block and will
> return as soon as the app is launched. However I believe you can
> wait for the app to finish with WaitForSingleObject if you wish.
>
> * If you use CreateProcess you can control the behavior however
> you want, but the use is much more complex.
>
> The whole area of starting processes and waiting for them is a mess in
> Windows, but with some work you can usually make it do what you want.
And to make an informed guess regarding the original problem:
1) There's some documentation on microsoft (which I couldn't find ATM)
regarding the granularity with which timestamps are updated on disk.
I remember that being about 30 seconds or such like for FAT.
2) We've had the problem a few times that modifications do not show up with
concurrent processes. I.e. process "notepad" writes a file, quits, and
process "svn" (which is alerted on notepad's exit) tests the file and finds
the old timestamp/size - a few seconds later it would find the correct info.
So the questions are:
- on which filesystem is the temporary commit message?
- does it help to set a batch file as EDITOR, when this batch file includes
something like
notepad "%1"
sleep 2
or, if you don't have sleep, use "choose" with a timeout.
Regards,
Phil
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Fri Dec 3 07:47:02 2004