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

[Martin Geisler]

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

> Let's move the discussion from the other thread over here.

No problem :)

>> 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 would really like to know how could I use a template and still
> receive data in this way ^_^.

That doesn't really matter. Right now I agree that the output is written
to stdou on a per changeset basis. But a future change to Mercurial
could make that stop (imagine that it is faster for Mercurial to write
the data for 10 changesets at a time).

> I haven't change this model to much from my last patchbomb, because
> I've got some problems in finding a changest.
>
> This is my template :
> "{rev}\\0{node}\\0{tags}\\0{branch}\\0{author}\\0{desc}\\0{date|isodate}\\0"
> And my parsing process is more like pointing to the right position.
>
> What kind of template could I use to know if where my changeset will
> be finish?
>
> The desciption could contain all kind of characters....

For JavaHg we first used a template with

   {node}\0 ... other fields ... \0{node}

with the idea that the changeset hash cannot appear in the commit
message (if it did, you would have broken the hash function).

We changed that later into a template with a \0 byte marking the
beginning of a changeset:

  https://bitbucket.org/aragost/javahg/commits/7855d21c99e1#chg-src/main/java/com/aragost/javahg/Changeset.java

I'm sorry to say that the commit message doesn't explain why the change
was made. I think it had something to do with how we reused the 'hg log'
parsing code for parsing 'hg incoming'. That command has two extra lines
of output in the top and then we might have thought it was easier to
skip those by searching for a \0 byte. Maybe Jan remembers more?

-- 
Martin Geisler
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 835 bytes
Desc: not available
URL: <http://selenic.com/pipermail/mercurial-devel/attachments/20130821/b6be746d/attachment.pgp>