[PATCH 01 of 10 shelve-ext v2] shelve: add an ability to write key-val data to a new type of shelve files

[Sean Farley]

Kostia Balytskyi <ikostia at fb.com> writes:

> # HG changeset patch
> # User Kostia Balytskyi <ikostia at fb.com>
> # Date 1484835841 28800
> #      Thu Jan 19 06:24:01 2017 -0800
> # Node ID d904df83e9ead56f65104e10d765c0157d647401
> # Parent  19a449c91ef14e691cf1347748473e0094fedc86
> shelve: add an ability to write key-val data to a new type of shelve files
>
> Obsolescense-based shelve only needs metadata stored in .hg/shelved
> and if feels that this metadata should be stored in a
> simplekeyvaluefile format for potential extensibility purposes.
> I want to avoid storing it in an unstructured text file where
> order of lines determines their semantical meanings (as now
> happens in .hg/shelvedstate. .hg/rebasestate and I suspect other
> state files as well).
>
> Not included in this series, I have ~30 commits, doubling test-shelve.t
> in size and testing almost every tested shelve usecase for obs-shelve.
> Here's the series for the curious now: http://pastebin.com/tGJKx0vM
> I would like to send it to the mailing list and get accepted as well,
> but:
> 1. it's big, so should I send like 6 patches a time or so?
> 2. instead of having a commit per test case, it more like
>    a commit per some amount of copy-pasted code. I tried to keep
>    it meaningful and named commits somewhat properly, but it is
>    far from this list standards IMO. Any advice on how to get it
>    in without turning it into a 100 commits and spending many
>    days writing descriptions?
> 3. it makes test-shelve.t run for twice as long (and it is already
>    a slow test). Newest test-shelve.r runs for ~1 minute.

Same for this, let's wait until after the freeze.