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

Iulian Stana julian.stana at gmail.com
Mon Aug 19 18:05:50 CDT 2013


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 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.


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".



> 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?

-- 
Iulian
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://selenic.com/pipermail/mercurial-devel/attachments/20130820/660deb4c/attachment.html>


More information about the Mercurial-devel mailing list