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 Thu, 07 Nov 2002 12:17:33 GMT, tmh at nodomain.org (Tony Hoyle) wrote: >On Wed, 06 Nov 2002 23:16:59 +0100, Bo Berglund ><bo.berglund at telia.com> wrote: > >>Where is this error generated? Is it generated as an exception inside >>the cvs taginfo processing or is it generated when cvs tries to start >>whatever program is specified in taginfo with this long command >>string? (This means that the error comes from Windows rather than from >>cvs). > >There error is generated by the command processor on NT. Exactly the >same code works fine under Unix, and there are no fixed limits in CVS. > >Taginfo needs changing, but it'll break all the existing scripts when >it happens, so I'm a bit reluctant... > >Tony What about this: 1) Add a config file switch such as FileSpecOnStdIn=1 or TagInfoFilesOnStdIn=1 (if we can't make this global, see below) 2) Change taginfo, commitinfo and loginfo processing such that with the switch above active they pass the list of files on StdIn instead. (Of course the list must be appended to whatever these scripts send now on StdIn, I think that taginfo actually does not use StdIn at all currently.) What you need to do after creating the string that was supposed to be put on the command line is just to append it to StdIn instead if the switch is active. This way it is possible to keep the compatibility with the old cvs system yet at the same time move the data to a channel that is not limited by Windows processing for those that need that. In principle the loginfo handling is also a potential case for this error, but only if a user commits changes to virtually all of his files and he has a large number of them. For tagging this scenario is quite common because often one tags the whole module and thus *all* files are affected. So if nothing else is possible then at least having a switch for taginfo would be very valuable, and in this case there is nothing existing on StdIn that we need to be concerned with. Just move the file list over from command line to StdIn and it will solve the problem (but controlled by the config switch of course). I would really appreciate this change to take place! /Bo (Bo Berglund, developer in Sweden)