list all paths from tag of remote hg repository without hg binary

[Gregory Szorc]

JSON output will simply be a different "style." Just like you can prefix
handlers with "<style>-" or add ?style= to the query string to get e.g.
atom or rss, you'll be able to use "json."

Pull @, run `hg serve` and access a URL like http://localhost:8000/json-tags
.

We certainly could add any of the gazillion REST declaration resources to
hgweb's output. But at this point I'd like to make the API useful by
emitting useful data. Bonus features can come later. Or they can come now.
Patches welcome.

On Tue, Mar 31, 2015 at 2:01 AM, anatoly techtonik <techtonik at gmail.com>
wrote:

> On Mon, Mar 30, 2015 at 11:44 PM, Gregory Szorc <gregory.szorc at gmail.com>
> wrote:
>
>> On Mon, Mar 30, 2015 at 7:58 AM, anatoly techtonik <techtonik at gmail.com>
>> wrote:
>>
>>>
>>> On Mon, Mar 30, 2015 at 3:41 PM, Augie Fackler <raf at durin42.com> wrote:
>>>
>>>>
>>>> On Mar 30, 2015, at 7:41 AM, anatoly techtonik <techtonik at gmail.com>
>>>> wrote:
>>>>
>>>> > Hi,
>>>> >
>>>> > I need to get stats about files additions and removals from Python
>>>> history. That means getting the list of all file paths for every existing
>>>> tag. It there a way to do this remotely, without clone checkout?
>>>> >
>>>> > I want the tool to be a simplistic web/JS dashboard that updates
>>>> itself automatically and doesn't run any server side binaries. Ideally I
>>>> want to do this operation in a series of web requests:
>>>> >
>>>> > 1. get all tags
>>>> > 2. for each tag get all files
>>>> >
>>>> > The output of `hg locate` is the ideal. Is it possible to get that
>>>> without hg binary and for remote repository?
>>>>
>>>> You can screen-scrape the output of hgweb, but I’m guessing the server
>>>> admins won’t like you much.
>>>>
>>>> Also, you’d be at the mercy of any HTML format changes in hgweb.
>>>>
>>>
>>> Is it possible to add a REST interface to hgweb? I doubt that the common
>>> operations will change often. As a side benefit, there will also be a
>>> details API usage stats.
>>>
>>
>> The URI space for hgweb is already RESTful. What's missing is an output
>> format tailored for machines. "raw" is the best we have, but it isn't good
>> enough.
>>
>> I started on a patch series to add a "json" style for the web interface
>> so ?style=json or "json-<cmd>" in the URIs would produce JSON (which could
>> be read by machines). I'd very much like to finish that work.
>> https://hg.mozilla.org/users/gszorc_mozilla.com/hg/rev/json-style if
>> someone wants to beat me to it.
>>
>> Also, the hgweb help output in @/to-be-3.4 contains detailed
>> documentation on all the URIs and their arguments.
>>
>
> Nice to know. What is the URL for that @/to-be-3.4 to look at?
>
> Maybe it will be better to add some integrity for REST APIs by defining a
> dedicated URL like https://hg.python.org/cpython/rest as an endpoint for
> both information about API and calls to it. Maybe with a link to some
> machine readable speccy like https://apiblueprint.org/ or http://raml.org/
>
> --
> anatoly t.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://selenic.com/pipermail/mercurial/attachments/20150401/0e875dcb/attachment.html>