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)