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.
Has there been any resolution on this? "Bo Berglund" <bo.berglund at telia.com> wrote in message news:5blpsucf7bli6ltqeha5mfqjtncio2fn2o at 4ax.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)