[PATCH 51 of 55 RFC c-hglib:level1] hg_tip: creating a high level function for mercurial tip command

[Idan Kamara]

On Sun, Sep 15, 2013 at 11:45 AM, Giovanni Gherdovich <
g.gherdovich at gmail.com> wrote:

> Hello Idan and Iulian,
>
> 2013/9/15 Idan Kamara <idankk86 at gmail.com>:
> > On Sat, Sep 14, 2013 at 3:34 PM, Iulian Stana <julian.stana at gmail.com>
> > wrote:
> >>
> >>
> >>>> + *
> >>>> + * \param handle The handle of the connection, wherewith I want to
> >>>> communicate
> >>>> + * \param callback A function that will handle error data.
> >>>> + *                 A NULL pointer will ignore error data.
> >>>
> >>>
> >>> What meaningful thing can a user do in this callback?
> >>>
> >>
> >>
> >> What ever he wants to do with error data, print it do the stderr, store
> in
> >> some place
> >> or I don't know parse this data in his own way is his decision.
> >
> >
> > Parsing error data is a bit of a problem in Mercurial, since its output
> > isn't guaranteed to be stable between releases.
> > But more importantly, I don't think there's anything meaningful to do
> when
> > 'hg tip' fails..
> >
> > You already have errno to check for command errors, does it also expose a
> > generic 'command failed' error code?
> > If so, you could use that and store the error string somewhere, and have
> > strerror (or similar), return it.
>
> They idea behind a callback to handle error messages is to let the user
> decide if (1) print the err msg somewhere, like dialogue box or stderr or
> (2) ignore.
> Below I paste the IRC transcripts of the discussion we had with Matt
> at the time.
>
>
> >>>> + * \param argument The option list. Will contain all option that you
> >>>> wish.
> >>>
> >>>
> >>> If you let the user pass in more arguments, it has the potential of:
> >>>
> >>> 1) breaking your changeset parser (user passed --template)
> >>> 2) leaving unparsed data after you successfully parsed the changeset
> (not
> >>> sure how you deal with that)
> >>>
> >>
> >> The last --template will overwrite all preview templates probably I must
> >> tell in
> >> documentation that is not allowed to use other template...
> >>
> >>
> >> hg tip --template '{rev}' --template '{node}' --template 'Template -
> {rev}
> >> - {node}\n'
> >>
> >>> I'm not sure you really want that.
> >>
> >>
> >> I really don't want to leave unparse data.
> >
> >
> > Right, so I'm not sure if you agree there's an issue here..
>
> I agree that there is an issue here.
> We don't just proxy commands trasparently to commandserver,
> we inject a template that must be respected.
>
> What does python-hglib and JavaHG do about that?


The high level interface doesn't let you pass arbitrary flags, it is
'typed', so you
can only pass what each command expects (excluding --template/style or other
flags that might alter the output in an unexpected way).
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://selenic.com/pipermail/mercurial-devel/attachments/20130917/f9d01051/attachment.html>