[PATCH evolve-ext-V5] evolve: add new methods _evolvestatewrite, _evolvestateread, _evolvestatedelete

Bryan O'Sullivan bos at serpentine.com
Tue Jan 26 18:01:59 CST 2016


On Tue, Jan 26, 2016 at 3:43 PM, Shusen LIU <liushusen at fb.com> wrote:


> +## Parsing and writing of version "0"
>

We have historically avoided numbered versions in favour of capabilities. I
don't have a strong opinion on whether to do that here, just raising this
as diverging from that practice.


> +#
> +# The file contains two line.
> +# First line is the version number.
> +# Second line is the the data in json format
> +
> +_fm0evolvestateversion = 0
>

What does _fm indicate here?


> +
> +def _fm0evolvestateread(repo):
> +    serialized_data = repo.vfs.read('evolvestate').split('\n')[1]
> +    data = dict([(str(k), str(v))
> +                 for k,v in json.loads(serialized_data).iteritems()])
>

This doesn't make sense to me. Why are you turning everything in the
serialised json into strings? Wouldn't they already be in the desired form
if you wrote them out?


> +    return data
>

This is redundant.


> +# mapping to read/write various evolvestate formats
> +# <version> -> (reader, writer)
> +formats = {_fm0evolvestateversion: (_fm0evolvestateread,
> _fm0evolvestatewrite),}
> +defaultversion = _fm0evolvestateversion
>

I think you should really put these functions in a class and refer to that
class. My feeling is that using a tuple is less elegant.

+
> +def _evolvestatewrite(repo, data, version=defaultversion):
> +    formats[version][1](repo, data)
>

And here's why I don't like the tuple: now we've some indexing into a
nested structure, instead of a reference to a name.

+def _evolvestateread(repo):
> +    diskversion = int(repo.vfs.read('evolvestate').split('\n')[0])
>

If the evolve state is big, then reading the first line is going to become
very expensive because you're reading the entire file.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://selenic.com/pipermail/mercurial-devel/attachments/20160126/ea56b992/attachment.html>


More information about the Mercurial-devel mailing list