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

login
register
mail settings
Submitter Kostia Balytskyi
Date Jan. 19, 2017, 3:10 p.m.
Message ID <d904df83e9ead56f6510.1484838628@devvm1416.lla2.facebook.com>
Download mbox | patch
Permalink /patch/18254/
State Deferred
Headers show

Comments

Kostia Balytskyi - Jan. 19, 2017, 3:10 p.m.
# HG changeset patch
# User Kostia Balytskyi <ikostia@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.
Sean Farley - Jan. 19, 2017, 7:27 p.m.
Kostia Balytskyi <ikostia@fb.com> writes:

> # HG changeset patch
> # User Kostia Balytskyi <ikostia@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.

Patch

diff --git a/hgext/shelve.py b/hgext/shelve.py
--- a/hgext/shelve.py
+++ b/hgext/shelve.py
@@ -62,7 +62,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'
 
@@ -70,6 +70,9 @@  patchextension = 'patch'
 # generic user for all shelve operations
 shelveuser = 'shelve@localhost'
 
+class obsshelvefile(scmutil.simplekeyvaluefile):
+    KEYS = [('node', True)]
+
 class shelvedfile(object):
     """Helper for the file storing a single shelve
 
@@ -153,6 +156,12 @@  class shelvedfile(object):
         bundle2.writebundle(self.ui, cg, self.fname, btype, self.vfs,
                                 compression=compression)
 
+    def writeobsshelveinfo(self, info):
+        obsshelvefile(self.vfs, self.fname).write(info)
+
+    def readobsshelveinfo(self):
+        return obsshelvefile(self.vfs, self.fname).read()
+
 class shelvedstate(object):
     """Handle persistence during unshelving operations.