[cvsnt] Re: Problems with 2.0.62.1849....

Bo Berglund bo.berglund at telia.com
Mon Jan 17 23:01:51 GMT 2005


Community technical support mailing list was retired 2010 and replaced with a professional technical support team. For assistance please contact: Pre-sales Technical support via email to sales@march-hare.com.


On Mon, 17 Jan 2005 21:59:44 +0000, Tony Hoyle <tmh at nodomain.org>
wrote:

>Bo Berglund wrote:
>> The thing is that if a call parameter is surrounded by double quotes
>> in the loginfo script line then it behaves as before. So this can be
>> solved using another edit to the scriptfile.
>
>Shouldn't be necessary in that case - Win32 should behave as Unix, 
>otherwise it's not portable.  I've got to find a way around it but no 
>idea how at the moment.  I am passing the requisite number of quotes to 
>CreateProcess...

I had a problem once when dealing with the script engine for the
ViewCvs installer. The engine filtered out all quotes and made the
call impossible to do until I used a completely different char as
quote and then inside the script itself I replaced it with the quotes.
That was a thingie with the Microsoft script engine and a true
workaround....

>> BUT, in build 1849 I have yet to be able to do this, it seems like the
>> suplied PID is not the cvs.exe process id or something else is
>> screwing things up. I am trying to track this down now, but it is hard
>> since I cannot use the debugger on this problem. Must add logging code
>> and run trials...
>
>It is the PID... looks the same as the one in task manager to me.
>OTOH if you cleanup on postcommand there's no problem with just using 
>the pid as it can't get reused until you've finished.

The problem is that the PID is used when collecting the data from the
various calls to loginfo cvs does on multi-directory commits. In order
to really get all data into a single email there is a delay
(configurable) of about a minute in most cases before the data are
actually collected into an email and sent. During this time the cvs
process has exited so the PID is no longer valid and can be reused.

If during  that time the PID actually gets reused then the same temp
folder will be used for the next commit and the data is corrupted.
That's why I had to get something else, so I dig out the handle to the
main cvs process using reverse lookup from the PID and then I get the
process start time (in nanoseconds) and use the least significant 32
bits as a number I am rather confident will not repeat in a while to
create the temp folder for the collection of data.
Since there are a separate call to CVSMailer for each en every dir
processed CVSMailer cannot keep this info inside its own memory space
(new instances all the time), but so far on every call from the same
cvs process I could calculate the exact same start time in nanoseconds
if the call was from the same commit.

Anyway,
I have now added code to first check the process ID using hex codeing
assumption, then if that fails trying decimal assumption. This has in
fact worked out for the temp dir. But I had to dig a bit deeper than I
thought at first, so it was not until a couple of minutes ago I had
that part working.

Remains to find out what to do about CVSROOT, it still screws up on
me. Cvs is sending in the folder name instead of the logical name as
supplied by the user, and I cannot use that.


/Bo
(Bo Berglund, developer in Sweden)



More information about the cvsnt mailing list
Download the latest CVSNT, TortosieCVS, WinCVS etc. for Windows 8 etc.
@CVSNT on Twitter   CVSNT on Facebook