[PATCH 2 of 3] changeset: adjust json output to use new/old (BC)

timeless timeless at gmail.com
Fri Apr 15 13:00:11 EDT 2016


On Fri, Apr 15, 2016 at 12:17 PM, Yuya Nishihara <yuya at tcha.org> wrote:
> On Wed, 13 Apr 2016 12:14:35 -0500, timeless wrote:
>> # HG changeset patch
>> # User timeless <timeless at mozdev.org>
>> # Date 1460548060 0
>> #      Wed Apr 13 11:47:40 2016 +0000
>> # Node ID 4161598737bc141a062d8fa0d2c90da823e5b6c9
>> # Parent  57f09cb9c2e69b0e8ef89cd21758722ba7e07ff6
>> changeset: adjust json output to use new/old (BC)
>>
>> The previous json structure was not friendly to strongly structured parsing.
>
> Maybe I'm dumb, but I really can't understand what the "strongly structured
> parsing" is. Could you elaborate a little more?

Basically being able to do : {object}.{well-known-property-name}

for a in copies:
   print(a.new.path, a.old.path)

Upon review "new" is a bad choice since some languages would object.
I'm actually not sure if this is a path or an abspath, I should re-review.

>
>> --- a/tests/test-log.t
>> +++ b/tests/test-log.t
>> @@ -524,7 +524,7 @@
>>      "tags": ["tip"],
>>      "parents": ["2ca5ba7019804f1f597249caddf22a64d34df0ba"],
>>      "files": ["dir/b", "e"],
>> -    "copies": {"e": "dir/b"}
>> +    "copies": [{"new": {"path": "e"}, "old": {"path": "dir/b"}}]
>
> Why are only "copies" wrapped by {"path": ...} ?

If we have renames, it should affect that too...
Basically, the problem is that the old system used filepaths as keys,
which makes key based parsing hard...


More information about the Mercurial-devel mailing list