[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: taginfo: Arg list too long

From: Paul Sander
Subject: Re: taginfo: Arg list too long
Date: Fri, 1 Dec 2000 16:54:40 -0800

There was a discussion about this some years ago, and no one took seriously
the possibility of overflowing a command line because at the time all of the
platforms in use gave large enough blocks of memory (well over 1MB) to
accomodate the gunky *info interface.

I proposed piping the paths into the script, and there was some colorful
discussion about programming style.  Another advantage to this is that the
*info script writer has the option to divide up the paths arbitrarily,
rather than being required to process each path in per-directory groups.

I kinda doubt that such a mechanism will be implemented anytime soon, though.

--- Forwarded mail from address@hidden

address@hidden writes:

> I have a script that is invoked from taginfo to record what is tagged with 
> "cvs tag" (since the history file only includes "cvs rtag" for some reason).  
> Someone was tagging a HUGE module with "cvs rtag" and got the following:
>    cvs server: cannot exec /sccripts/cvstaglogger: Arg list too long
>    cvs server: Pre-tag check failed
>    cvs [server aborted]: correct the above errors first!

That's a design flaw in the *info hooks !  Hooks like taginfo that need
lots of input should take it from stdin, not the command line.  Your only
recourse is to change your repository.  If I remember correctly, taginfo
is invoked once per directory, so you can avoid the bug by limiting the
number of files per directory.  Bletch.

> Is there some OS parm I can tweak, or can CVS be changed to split the calls 
> up if the number of files is so large?

Maybe CVS can be hacked.  Split the arglist in chunks, invoke taginfo mutliple
times, and allow the tag if and only if all invocations accept the tag.  This
is less than perfect because any logging performed by the initial invocations
won't be undone.

The correct fix will have to break backward compatibility.  Or maybe we should
create a new hook interface (loghook, taghook, commithook...), keeping the old
one (loginfo, taginfo...) for back-compatibility.

--- End of forwarded message from address@hidden

reply via email to

[Prev in Thread] Current Thread [Next in Thread]