> On Mar 25, 2017, at 7:35 PM, Kostia Balytskyi <kobal...@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 <ikos...@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@mercurial-scm.org >>> https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel >> _______________________________________________ >> Mercurial-devel mailing list >> Mercurial-devel@mercurial-scm.org >> https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel _______________________________________________ Mercurial-devel mailing list Mercurial-devel@mercurial-scm.org https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel
