why does the cmdserver use a 4-byte length field?

Idan Kamara idankk86 at gmail.com
Tue Jul 5 06:12:51 CDT 2011


On Mon, Jul 4, 2011 at 4:45 PM, Laurens Holst <laurens.nospam at grauw.nl>
wrote:
>
> Op 04-07-11 15:34, Idan Kamara schreef:
>>
>> On Mon, Jul 4, 2011 at 4:22 PM, Laurens Holst<laurens.nospam at grauw.nl>
 wrote:
>>>
>>> Op 01-07-11 15:32, Idan Kamara schreef:
>>>
>>> On Fri, Jul 1, 2011 at 1:13 AM, Jesper Schmidt<schmiidt at gmail.com>
 wrote:
>>>>
>>>> I mean a 2-byte length field seems to be enough for the input channels.
>>>
>>> I think in today’s day and age you shouldn’t worry about two bytes. Any
performance difference it would make will be basically immeasurable.
>>>
>>> What you *should* worry about is that the protocol does not impose
arbitrary limitations that may become a serious limitation in the future.
Y’know, like FAT32’s 4GB file size limit (Mercurial’s not that different
from a file system... :)).
>>
>> Mercurial already has internal limitations on the file sizes, see:
>> http://mercurial.selenic.com/wiki/HandlingLargeFiles
>
> Yes but if the large files problem is fixed in the future, should the
command server ‘by design’ impose an additional obstacle to handling large
files?

I don't see that happening anytime soon, but like I said, the server can
always send stuff in chunks <4GB when that day comes.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://selenic.com/pipermail/mercurial-devel/attachments/20110705/6476b8ec/attachment.htm>


More information about the Mercurial-devel mailing list