[PATCH 2 of 2 RFC] c-hglib: hg_log() level 1 function

[Martin Geisler]

Iulian Stana <julian.stana at gmail.com> writes:

Hi Iulian,

Thanks for quoting the reply! :)

> I don't really know if this is a problem or not, but I think that
> users could have all kinds of settings in there configuration files,
> and the changesets could be received different from user to user in
> case of using the 'hg log' command without any template.
>
> Meanwhile I've made some examples, using a template. From those
> examples the single notable thing is that the command server is
> sending a changeset in a call. (channel, data_length, changeset fit
> the template). Probably, the concern thing is that somehow in the
> message data, there will be just a part of the changeset.

I believe that the command server is allowed to send data back to you as

  'o', 32, 'changeset:   19527:f37b5a17e6a0\n'
  'o', 32, 'branch:      stable\ntag:        '
  'o', 32, ' 2.7\nuser:        Kevin Bullock '
  'o', 32, '<kbullock at ringworld.org>\ndate:  '
  'o', 32, '      Thu Aug 01 21:43:14 2013 -'
  'o', 32, '0500\nsummary:     bookmarks: pul'
  'o', 32, 'l --update updates to active boo'
  'o', 29, 'kmark if it moved (issue4007)'

if we somehow found out that it was more efficient to buffer data in a
32 byte buffer before writing it to stdout.

> I agree, that :
>
>> This is the same situation as when working with TCP sockets: a client
>> cannot "see" the chunks the server used when writing the reply to the
>> socket. All the client sees is a stream of data.
>
> But in our case the, our message has a header, that tells use the
> length of data. Probably is not what you want to point.

You're right that there is a header -- but that header only tells you
the size of the chunk being written on stdout. You don't generally know
what a "chunk" is. A chunk may be a line in 'hg log' output, but that's
not part of the specification of the command server.

> Also: about putting chunks together and then parse, I think that is a
> very costly process. If the data comes in fields I think that is
> better to "parse"/"put directly in a place".

You can only rely on this if it is specified somewhere. I don't know of
such a specification.

>> We decided that a high-level client would get a ArraysList back with
>> all the parsed changesets and made the internal iterator API private.
>> One could also have exposed the iterator API instead.
>
> It would be nice to have the changesets in an ArraysList, but the C
> language is not providing a List implementation, yes I could simulate
> the list, but there will be a problem with the length of data. If I
> passing the ArrayList back to the user, this will mean that I must
> save in my memory the entire amount of data(probably 500GB of data),
> or there is any other possibility of doing this operation without
> saving the data in memory?

We're just talking about the meta data you see when you call 'hg log',
not the file content itself. JavaHg wont let you use the --patch flag
for log so the output shouldn't be very big (if you want patches you're
supposed to call 'hg diff' later).

-- 
Martin Geisler