Sketch the header for level 1
idankk86 at gmail.com
Mon Aug 5 02:58:23 CDT 2013
On Fri, Aug 2, 2013 at 3:59 PM, Giovanni Gherdovich
<g.gherdovich at gmail.com>wrote:
> Hello Idan,
> 2013/8/2 Idan Kamara <idankk86 at gmail.com>
> > On Thu, Aug 1, 2013 at 2:18 PM, Iulian Stana <julian.stana at gmail.com>
> > > Even if level 0 is not validated yet, I am exploring what level 1
> might look like.
> > > Here are some sketches:
> > >
> > > Start with some basic commands that everybody will use.
> > > (add, commit, push, pull, log, import/export, merge, verify)
> > What added value do these functions have over calling rawcommand?
> > The signature isn't command specific, and the return value is unparsed.
> As far as I have understood, it goes like this:
> hg_add (to name one of them) doesn't just call hg_rawcommand, but calls:
> [... as many hg_rawread as needed, output is read in 4k sized chunks]
> other commands (like hg_import) will require calls to hg_rawwrite too
> (again, data to be written is split into chunks).
> The exact sequence _is_ command specific.
> You can see a fiew example in main.c here:
> You also say "the return value is unparsed."
> Well, it cannot be otherwise; the only "structured" piece of data is
> the content of the 'r' channel (read by hg_exitcode).
> The rest of the output, namely 'o' and 'e' channels, is just flat text.
> It cannot be parsed since the content and format can change from
> a hg release to the next. So the only way to deal with it is to take it as
> it is.
That's not true and if it were these libraries we're trying to create around
hg wouldn't be all that useful.
You can see here that python-hglib test suite runs on hg versions going
back to 1.9.3 and have survived several big releases with only a few changes
in Mercurial's output during that time, which in some cases would have gone
unnoticed had python-hglib been more liberal in parsing the output.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Mercurial-devel