Sketch the header for level 1

Iulian Stana julian.stana at
Thu Aug 1 06:18:46 CDT 2013

 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)

add command:
1) int hg_add(hg_handle *handle, char *argv[], size_t argc);
The return values for this function is the exitcode received from cmdserver
for this command.
You can still have data on cmdserver output channels (error/ output)
    hg add “a wrong file” “a good file” --debug
>From the error data you will know each of those two files is the corrupt

2) I think that the best solution for all those commands will be to return
a structure of the following form:
struct hg_ret{
    int exitcode;
    char *out_data;
    char *err_data;

In this way the user will have his data (error/ output) and will have the
chance to make what ever he want with it. (parsing, process, ignore) . I
know that this thing is not following the read paradigm ( ssize_t read(int
fd, void *buf, size_t count);), but I think that could fit well in our case.

– from now on I will adopt this paradigm ( using the return structure),
it's just a sketch all the ideas and comments are welcomed –

Following this paradigm I sketch the rest of the mercurial command. Also I
made a small comparison with python-hglib.

commit command
  - hg_ret hg_commit(hg_handle *handle, char *argv[], size_t argc);
The commit command on python-hglib is returning some parse data ( rev, node)
(I think that will be a later discussion about this, parsing data, for now
I will just put the data on hg_ret structure)

pull/push commands:
  - hg_ret hg_pull(hg_handle *handle, char *argv[], size_t argc);
  - hg_ret hg_push(hg_handle *handle, char *argv[], size_t argc);
For those commands python-hglib return a bool value that indicate the
success or the failing/nothing happened.

log command:
  - hg_ret hg_log(hg_handle *handle, char *argv[], size_t argc);
On this case the python-hglib return the log data. On our case we can put
the out data on out_data field from hg_ret structure.

export/import commands:
  - hg_ret hg_export(hg_handle *handle, char *argv[], size_t argc);
  - hg_ret hg_import(hg_handle *handle, char *argv[], size_t argc);

For export command the python-hglib will return the output data, if there
is no output file where to write it. In our case the data will be put on
out_data field from hg_ret if there is no specific file in argv list.

For import command the python-hglib will return nothing, in our case the
exitcode will be the only interesting thing.

merge command:
  - hg_ret hg_merge(hg_handle *handle, char *argv[], size_t argc, void
(*prompt)(void *));

In the signature function will be a prompt function that will handle the
For this function the python-hglib will return nothing, in out case the
exitcode will be put on hg_ret structure.

verify command:
  - hg_ret hg_verify(hg_handle *handle, char *argv[], size_t argc);

The output data will be set on out_data field and the error data will be
set on err_data field.

>From a first point, this paradigm could look nice, but will give user a lot
of freedom. Sometime this thing could be good but I don't know exactly if
in our case will be the best choice.
If we adopt this paradigm, the main problem will be to make a strong
documentation, for how the argument list must look and what options must

A good thing for this paradigm is that of maintaining the same signature
for almost all functions.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the Mercurial-devel mailing list