atom feed15 messages in com.selenic.mercurial-develSketch the header for level 1
FromSent OnAttachments
Iulian StanaAug 1, 2013 4:18 am 
Idan KamaraAug 2, 2013 3:59 am 
Kevin BullockAug 4, 2013 2:11 pm 
Giovanni GherdovichAug 4, 2013 10:33 pm 
Giovanni GherdovichAug 5, 2013 1:29 am 
Idan KamaraAug 5, 2013 1:43 am 
Iulian StanaAug 5, 2013 5:44 am 
Iulian StanaAug 5, 2013 5:52 am 
Matt MackallAug 5, 2013 11:10 am 
Kevin BullockAug 5, 2013 8:53 pm 
Martin SchröderAug 6, 2013 3:58 am 
Iulian StanaAug 6, 2013 8:42 am 
Iulian StanaAug 17, 2013 3:25 am 
Giovanni GherdovichAug 18, 2013 5:56 am 
Iulian StanaAug 18, 2013 11:13 am 
Subject:Sketch the header for level 1
From:Iulian Stana (
Date:Aug 1, 2013 4:18:46 am

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

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

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