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 22:26:07 +0100, Bo Berglund
<bo.berglund at telia.com> wrote:
Clicked the wrong button so the message was sent too early...
>>>
>>> 2) The list of files and versions is no longer coming in as they did before
>>> in the last call argument.
>>>
>>> All previous versions sent the module name followed by the file,revision
>>> list as the last parameter of the call.
>>
>>This one does too - not sure why your script is seeing it as different
>>arguments. The cvsnt-commits messages are generated by a perl script
>>under Unix that has the same requirements.
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.
>>Perhaps Win32 is doing something odd to the argument list...
I am programming in Delphi and I retrieve parameters via the
ParamStr(n) function call. It will give me exactly the n:th command
line parameter and ParamStr(5) used to retrieve the list of files as a
space separated list all within a single parameter.
So previously cvs.exe obviously surrounded the %{sVv} expansion with a
couple of double quotes, which are now gone....
I can solve this by the double quote trick, but I have yet to test if
it is backwards compatible so old installations will be able to use it
too.
>>
>>> 3) The $CVSPID does not supply the same number as before...
>>> I use CVSPID to find the process information for the CVSNT instance calling
>>> the script.
>>> I do this in order to create a separate temp dir for each cvs process to
>>> store consolidating information in.
>>
>>The only thing you can guarantee about CVSPID is it's the same for
>>scripts called by the same process. It may or may not be useful for
>>anything else.. On win32 and Unix it's the result of getpid()... not
>>necessarily on all platforms though.
I need the process identifier to go backwards to the calling cvs.exe
process in order to separate them if there are many simultaneous
calls. I once upon a time relied on the PID number itself, but it was
not good enough since Windows resused PID:s quite early after an old
process had terminated so there were mixups. Now (since years ago) I
use PID to query Windows for more data on the cvs process and I use
this to separate the calls from each other.
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...
>>Sending it as a hex number is bizarre... I didn't know the old version
>>did that.
Well, I have now entered code in CVSMailer that will first use the
CVSPID as supplied in hex, but if it fails to locate the CVSNT temp
folder using hex then I fall back to decimal decoding.
This has shown that the new number is actually decimal. It really WAS
hex before!
>>> 4) In 1849 the $CVSROOT does not transfer the root used by the call.
>>> What is instead thrown in is the physical path to the root, of course this
>>> plays havoc with the parsing of the data too.
>>
>>You could replace $CVSROOT with %r/%p, and it'd do the same. I'm not
>>sure that $CVSROOT should be virtual though, as you can't do things like
>>'echo foo >>$CVSROOT/output' otherwise.
$CVSROOT has always (up to now) been the root supplied by the calling
user. It also mirrors any case strangeness the client had on the
cvsroot settings, for example if a module in a repository /Test was
checked out using /TEST by the client then the result of $CVSROOT on a
commit from him would be /TEST. So it always was the client side
CVSROOT and this is then used against the registry to find the true
physical path via the nameing system you employ. But thta has broken
now.
>>OTOH I'd rather maintain backward compatibility as much as possible, so
>>I may have to reimplement the problem!
>>
>>> Should I go on sending my findings to you or should I post something to the
>>> group as well??
>>
>>Best to CC the group so it gets archived.
OK, that's what I'm doing now.
Please excuse the rather lenghty posts on this, I have to explain what
I see...
/Bo
(Bo Berglund, developer in Sweden)