On Wed, Jan 23, 2002 at 10:16:30AM -0500, Greg Hudson wrote:
> On Tue, 2002-01-22 at 19:16, Greg Stein wrote:
> > I guess it might be possible to write a tool that directly calls exec() so
> > that you can avoid the shell's command line length, but that problem is
> > still there.
>
> In general, exec() is to blame, not the shell. However, the limits
> involved are really pretty big.
>
> > However, the simple fact remains that there are limits to the length of the
> > command line. That limits the number of files/dirs that can be specified.
> > Thus, having something like --file-list list-o-files.txt would be helpful.
>
> I would think we should implement this after someone has a real live
> problem with command-line length limits, not before. (Unless Windows
> has a really short command-line length limit. But we should verify that
> rather than just guessing.)
In Win9[58] the limit defaults to 127 characters, but you can jack it up to
250.
I've been told, but haven't verified, that WinNT/2K are also limited
to 250.
I don't know about XP.
In my svn repository the average path length is 30 chars. That will make
space pretty tight on Win32 command lines.
I don't know what HP/UX's limits are, but I do rememember needing to
do "find . | xargs foo" rather than "foo *" on many occasions while
working with HP/UX 9.x and 10.x
>
> On the other hand... I don't see why Karl is so paranoid about parsing
> the log message and letting people remove parts of the commit. It
> doesn't feel like a rat's nest to me.
Me neither, but I'm willing to settle for the "--file-list" command-line
argument. I'm also willing to provide a patch.
--ben
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Sat Oct 21 14:36:58 2006