[PATCH 02 of 10 shelve-ext v4] shelve: add an ability to write key-val data to a new type of shelve files
Augie Fackler
raf at durin42.com
Sun Mar 26 16:38:50 EDT 2017
> On Mar 25, 2017, at 7:35 PM, Kostia Balytskyi <kobalyts at outlook.com> wrote:
>
> On 21/03/2017 21:48, Augie Fackler wrote:
>
>> On Sat, Mar 11, 2017 at 01:00:21PM -0800, Kostia Balytskyi wrote:
>>> # HG changeset patch
>>> # User Kostia Balytskyi <ikostia at fb.com>
>>> # Date 1489186989 28800
>>> # Fri Mar 10 15:03:09 2017 -0800
>>> # Node ID 13c8fb8e722fd0563a83e601bb784694535268f1
>>> # Parent ca01391d61f5725c4fc79ccffe0c8e2d6dbb97f0
>>> 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.
>> Ouch. It might make sense to have a test-shelve-obs.t that is the
>> parallel universe version, so they can run in parallel.
>
> Can do. Should I send 1000+ lines patch or should I send a series of ~30 patches?
> I can also try to split it into multiple series (which does not really make semantical
> sense to me, but might make reviewing easier for people).
How awful is the diff if you do `hg copy test-shelve.t test-shelve-obsmarkers.t` and then do tweaks as needed to the new file?
>
>>> diff --git a/hgext/shelve.py b/hgext/shelve.py
>>> --- a/hgext/shelve.py
>>> +++ b/hgext/shelve.py
>>> @@ -63,7 +63,7 @@ testedwith = 'ships-with-hg-core'
>>>
>>> backupdir = 'shelve-backup'
>>> shelvedir = 'shelved'
>>> -shelvefileextensions = ['hg', 'patch']
>>> +shelvefileextensions = ['hg', 'patch', 'oshelve']
>>> # universal extension is present in all types of shelves
>>> patchextension = 'patch'
>>>
>>> @@ -154,6 +154,12 @@ class shelvedfile(object):
>>> bundle2.writebundle(self.ui, cg, self.fname, btype, self.vfs,
>>> compression=compression)
>>>
>>> + def writeobsshelveinfo(self, info):
>>> + scmutil.simplekeyvaluefile(self.vfs, self.fname).write(info)
>>> +
>>> + def readobsshelveinfo(self):
>>> + return scmutil.simplekeyvaluefile(self.vfs, self.fname).read()
>>> +
>>> class shelvedstate(object):
>>> """Handle persistence during unshelving operations.
>>>
>>> _______________________________________________
>>> Mercurial-devel mailing list
>>> Mercurial-devel at mercurial-scm.org
>>> https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel
>> _______________________________________________
>> Mercurial-devel mailing list
>> Mercurial-devel at mercurial-scm.org
>> https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel
More information about the Mercurial-devel
mailing list