[PATCH 1 of 2 RFC C-hglib] level 1 prototypes: model (2) commands (hd_add - like commands)

Iulian Stana julian.stana at gmail.com
Thu Aug 29 07:05:42 CDT 2013


I would like to receive some remarks for some of those commands. The rest
of
commands will have the same stories.

 +/**

> + * Example of description.
> + * \brief hg_add command for hglib API.
> + *
> + * Add the specified files on the next commit.
> + * If no files are given, add all files to the repository.
> + *
> + *      dryrun - do no perform actions
> + *      subrepos - recurse into subrepositories
> + *      include - include names matching the given patterns
> + *      exclude - exclude names matching the given patterns
> + *
> + * \param handle The handle of the connection, wherewith I want to
> communicate
> + * \param callback The handle function for error data.
> + * \param option The option list for mercurial add command.
> + * \retval exitcode  To indicate the end of add_command.
> + *
> + * errno can be:
> + *      - hg_rawcommand errors
> + * */
> +int hg_add(hg_handle *handle, int (*callback)(const char *msg, size_t
> len),
> +                                                       char *argument[]);
> +
>

Almost all of those commands have the same signature. I would like to
know if this signature will fit with mercurial or if I must change it.
The callback function will handle the error data.



> +/**
> + * bookmarks description.
> + * The return value will be a list of tuples(name, rev, node)
> + * */
> +hg_rev_entry_t *hg_bookmarks(hg_handle *handle, int(*callback)
> +                        (const char *msg, size_t len), char *argument[]);
> +
>

I would like to know if this command is a model (1) command... (probably
the list will have a lots of bookmarks).

Also I would like to know if the hg_rev_entry_t is the proper name for this
tuple.


> +/**
> + * branches description.
> + * The return value will be a list of tuples(name, rev, node)
> + * */
> +hg_rev_entry_t *hg_branches(hg_handle *handle, int(*callback)
> +                        (const char *msg, size_t len), char *argument[]);
> +
>

Same story like above.


> +/**
> + * commit description.
> + * The return value will be a tuple(rev, node)
> + * */
> +hg_rev_entry_t hg_commit(hg_handle *handle, int(*callback)
> +                        (const char *msg, size_t len), char *argument[]);
> +
>

The return value must be the exitcode or a tuple?



> +/**
> + * identify description
> + * I would really like to know how to parse this data...
> + * */
> +char *hg_identify(hg_handle *handle, int(*callback)(const char *msg,
> size_t len),
> +                                                       char *argument[]);
> +
>

What kind of data is this function returning ?

+/**
> + * merge function
> + * The merge function can have prompts.
> + * */
> +int hg_merge(hg_handle *handle, int (*callback)(const char *msg, size_t
> len),
> +               char (*prompt)(const char *msg, size_t len), char
> *argument[]);
> +
>

A command that can have prompts...



> +/**
> + * paths description
> + * retrun some parse data.
> + * I don't really know how this command is working and what data will
> deliver.
> + * */
> +hg_struct hg_paths(hg_handle *handle, int(*callback)(const char *msg,
> size_t len),
> +                                                       char *argument[]);
> +
>

What kind of data is this function returning ?

+/**
> + * tags description
> + * return a list of tags.
> + **/
> +hg_tags_struct *hg_tags(hg_handle *handle, int(*callback)
> +                        (const char *msg, size_t len), char *argument[]);
> +
>

Same story like bookmarks command.


> +/**
> + * tip description
> + * The return value will be a cset_entry structure (the tip cset will be
> parse
> + * and pass to directly to user). If any error occur, the return value
> will be a
> + * NULL pointer and errno will be set appropiate.
> + * */
> +hg_cset_entry_t *hg_tip(hg_handle *handle, int(*callback)(const char *msg,
> +                                               size_t len), char
> *argument[]);
> +
>

The return value is the parse changeset. It would be better to return the
exitcode and the cset structure to be put in command signature?



> +/**
> + * verify description
> + **/
> +hg_verify_entry_t *hg_verify(hg_handle *handle, int(*callback)
> +                               (const char *msg, size_t len), char
> *argument[]);
> +
>

What kind of data is this function returning ? How will verify structure
look like? What I will parse in this structure?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://selenic.com/pipermail/mercurial-devel/attachments/20130829/7bb8b696/attachment.html>


More information about the Mercurial-devel mailing list