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 firstname.lastname@example.org.
On Wed, 18 Sep 2002 09:48:38 +0100, "Tony Hoyle" <tmh at nodomain.org> wrote: >On Wed, 18 Sep 2002 09:47:20 +0200, Bo Berglund wrote: > >> In WinCvs we wee a message like this: The following character string is >> too long: (here follows a string showing all command line parameters >> enclosed in double quotes, but truncated a fair bit from the true end) >> cvs server: Pre-tag check failed >> cvs [server aborted]: correct the above errors first! >> >> It looks to me that this limitation is imposed by the server (CVSNT >> 57g). I use the same cvs.exe on both server and client. >> >It's probably a limit of the command processor on NT. There may be a way >of increasing it, but the easiest way is to replace cmd.exe with another >processor, such as 4NT. > >I'll have to find some other way of passing the filenames, since this'll >break commitinfo too if you commit enough stuff at one go. > >Tony Why not send it in through standard input? It is like how the notify script receives the list of users to notify. No limit on amount of text here. But of course then the CVSNT handling differs against the way the Linux/Unix CVS operates. Does this matter? I suggest that the files for tagging can be put on standard input just like they are tacked on the command line today. A space delimited list where every other item is a file and the other the revision. File names enclosed in double quotes to handle the embedded space issue (there should not be spaces anyway...). Or why not use comma separation like on the loginfo script input: filename,revision filename,revision etc. /Bo (Bo Berglund, developer in Sweden)