Thu, 10 Nov 2016 09:45:42 -0800 debugcommands: move debugbuilddag
Gregory Szorc <gregory.szorc@gmail.com> [Thu, 10 Nov 2016 09:45:42 -0800] rev 30402
debugcommands: move debugbuilddag And we drop some now unused imports from commands.py.
Wed, 17 Aug 2016 21:07:38 -0700 debugcommands: introduce standalone module for debug commands
Gregory Szorc <gregory.szorc@gmail.com> [Wed, 17 Aug 2016 21:07:38 -0700] rev 30401
debugcommands: introduce standalone module for debug commands commands.py is our largest .py file by nearly 2x. Debug commands live in a world of their own. So let's extract them to their own module. We start with "debugancestor." We currently reuse the commands table with commands.py and have a hack in dispatch.py for loading debugcommands.py. In the future, we could potentially use a separate commands table and avoid the import of debugcommands.py.
Mon, 14 Nov 2016 23:17:15 +0000 convert: migrate to util.iterfile
Jun Wu <quark@fb.com> [Mon, 14 Nov 2016 23:17:15 +0000] rev 30400
convert: migrate to util.iterfile
Mon, 14 Nov 2016 23:16:05 +0000 match: migrate to util.iterfile
Jun Wu <quark@fb.com> [Mon, 14 Nov 2016 23:16:05 +0000] rev 30399
match: migrate to util.iterfile
Mon, 14 Nov 2016 23:15:01 +0000 store: migrate to util.iterfile
Jun Wu <quark@fb.com> [Mon, 14 Nov 2016 23:15:01 +0000] rev 30398
store: migrate to util.iterfile
Mon, 14 Nov 2016 23:14:06 +0000 patch: migrate to util.iterfile
Jun Wu <quark@fb.com> [Mon, 14 Nov 2016 23:14:06 +0000] rev 30397
patch: migrate to util.iterfile
Mon, 14 Nov 2016 23:12:11 +0000 worker: migrate to util.iterfile
Jun Wu <quark@fb.com> [Mon, 14 Nov 2016 23:12:11 +0000] rev 30396
worker: migrate to util.iterfile
Mon, 14 Nov 2016 23:32:54 +0000 util: add iterfile to workaround a fileobj.__iter__ issue with EINTR
Jun Wu <quark@fb.com> [Mon, 14 Nov 2016 23:32:54 +0000] rev 30395
util: add iterfile to workaround a fileobj.__iter__ issue with EINTR The fileobj.__iter__ implementation in Python 2.7.12 (hg changeset 45d4cea97b04) is buggy: it cannot handle EINTR correctly. In Objects/fileobject.c: size_t Py_UniversalNewlineFread(....) { .... if (!f->f_univ_newline) return fread(buf, 1, n, stream); .... } According to the "fread" man page: If an error occurs, or the end of the file is reached, the return value is a short item count (or zero). Therefore it's possible for "fread" (and "Py_UniversalNewlineFread") to return a positive value while errno is set to EINTR and ferror(stream) changes from zero to non-zero. There are multiple "Py_UniversalNewlineFread": "file_read", "file_readinto", "file_readlines", "readahead". While the first 3 have code to handle the EINTR case, the last one "readahead" doesn't: static int readahead(PyFileObject *f, Py_ssize_t bufsize) { .... chunksize = Py_UniversalNewlineFread( f->f_buf, bufsize, f->f_fp, (PyObject *)f); .... if (chunksize == 0) { if (ferror(f->f_fp)) { PyErr_SetFromErrno(PyExc_IOError); .... } } .... } It means "readahead" could ignore EINTR, if "Py_UniversalNewlineFread" returns a non-zero value. And at the next time "readahead" got executed, if "Py_UniversalNewlineFread" returns 0, "readahead" would raise a Python error without a incorrect errno - could be 0 - thus "IOError: [Errno 0] Error". The only user of "readahead" is "readahead_get_line_skip". The only user of "readahead_get_line_skip" is "file_iternext", aka. "fileobj.__iter__", which should be avoided. There are multiple places where the pattern "for x in fp" is used. This patch adds a "iterfile" method in "util.py" so we can migrate our code from "for x in fp" to "fox x in util.iterfile(fp)".
Thu, 10 Nov 2016 16:37:18 -0500 filterpyflakes: whitelist listcomp aliasing checking
Augie Fackler <augie@google.com> [Thu, 10 Nov 2016 16:37:18 -0500] rev 30394
filterpyflakes: whitelist listcomp aliasing checking The test change is because of how filterpyflakes is organized - a line number changed.
Thu, 10 Nov 2016 16:35:54 -0500 verify: avoid shadowing two variables with a list comprehension
Augie Fackler <augie@google.com> [Thu, 10 Nov 2016 16:35:54 -0500] rev 30393
verify: avoid shadowing two variables with a list comprehension The variable names are clearly worse now, but since we're really just transposing key and value I'm not too worried about the clarity loss.
Thu, 10 Nov 2016 16:35:10 -0500 revset: avoid shadowing a variable with a list comprehension
Augie Fackler <augie@google.com> [Thu, 10 Nov 2016 16:35:10 -0500] rev 30392
revset: avoid shadowing a variable with a list comprehension
Thu, 10 Nov 2016 16:34:43 -0500 revlog: avoid shadowing several variables using list comprehensions
Augie Fackler <augie@google.com> [Thu, 10 Nov 2016 16:34:43 -0500] rev 30391
revlog: avoid shadowing several variables using list comprehensions
Thu, 10 Nov 2016 16:33:41 -0500 minirst: avoid shadowing a variable in a list comprehension
Augie Fackler <augie@google.com> [Thu, 10 Nov 2016 16:33:41 -0500] rev 30390
minirst: avoid shadowing a variable in a list comprehension
Thu, 10 Nov 2016 16:33:23 -0500 hbisect: avoid shadowing a variable in a list comprehension
Augie Fackler <augie@google.com> [Thu, 10 Nov 2016 16:33:23 -0500] rev 30389
hbisect: avoid shadowing a variable in a list comprehension
Thu, 10 Nov 2016 16:33:07 -0500 filemerge: avoid shadowing a variable in a list comprehension
Augie Fackler <augie@google.com> [Thu, 10 Nov 2016 16:33:07 -0500] rev 30388
filemerge: avoid shadowing a variable in a list comprehension
Thu, 10 Nov 2016 16:32:51 -0500 color: avoid shadowing a variable inside a list comprehension
Augie Fackler <augie@google.com> [Thu, 10 Nov 2016 16:32:51 -0500] rev 30387
color: avoid shadowing a variable inside a list comprehension
Thu, 10 Nov 2016 16:32:38 -0500 memory: avoid shadowing variables inside a list comprehension
Augie Fackler <augie@google.com> [Thu, 10 Nov 2016 16:32:38 -0500] rev 30386
memory: avoid shadowing variables inside a list comprehension
Thu, 10 Nov 2016 03:15:41 -0800 shelve: move shelve-finishing logic to a separate function
Kostia Balytskyi <ikostia@fb.com> [Thu, 10 Nov 2016 03:15:41 -0800] rev 30385
shelve: move shelve-finishing logic to a separate function With future obs-based shelve, finishing shelve will be different from just aborting a transaction and I would like to keep both variants of this functionality in a separate function.
Thu, 10 Nov 2016 03:20:28 -0800 shelve: move unknown files handling to a separate function
Kostia Balytskyi <ikostia@fb.com> [Thu, 10 Nov 2016 03:20:28 -0800] rev 30384
shelve: move unknown files handling to a separate function This change has nothing to do with future obsshelve introduction, it is done just for readability purposes.
Thu, 10 Nov 2016 03:07:20 -0800 shelve: move actual created commit shelving to a separate function
Kostia Balytskyi <ikostia@fb.com> [Thu, 10 Nov 2016 03:07:20 -0800] rev 30383
shelve: move actual created commit shelving to a separate function Currently, this code does not have any branching, it just bundles a commit and saves a patch file. Later, obsolescence-based shelve will be added, so this code will also create some obsmarkers and will be one of the few places where obsshelve will be different from traditional shelve.
Thu, 10 Nov 2016 03:33:01 -0800 shelve: move 'nothing changed' messaging to a separate function
Kostia Balytskyi <ikostia@fb.com> [Thu, 10 Nov 2016 03:33:01 -0800] rev 30382
shelve: move 'nothing changed' messaging to a separate function This has nothing to do with the future obsshelve implementation, I just thought that moving this messaging to a separate function will improve shelve code readability.
Thu, 10 Nov 2016 03:26:31 -0800 shelve: move commitfunc creation to a separate function
Kostia Balytskyi <ikostia@fb.com> [Thu, 10 Nov 2016 03:26:31 -0800] rev 30381
shelve: move commitfunc creation to a separate function Special commitfuncs are created as closures at least twice in shelve's code and one time special commitfunc is used within another closure. They all serve very specific purposes like temporarily tweak some configuration or enable editor, etc. This is not immediately important to someone reading shelve code, so I think moving this logic to a separate function is a good idea.
Thu, 10 Nov 2016 03:24:07 -0800 shelve: move mutableancestors to not be a closure
Kostia Balytskyi <ikostia@fb.com> [Thu, 10 Nov 2016 03:24:07 -0800] rev 30380
shelve: move mutableancestors to not be a closure There's no value in it being a closure and everyone who tries to read the outer function code will be distracted by it. IMO moving it out significantly improves readability, especially given how clear it is what mutableancestors function does from its name.
Thu, 10 Nov 2016 03:22:55 -0800 shelve: move shelve name generation to a separate function
Kostia Balytskyi <ikostia@fb.com> [Thu, 10 Nov 2016 03:22:55 -0800] rev 30379
shelve: move shelve name generation to a separate function This has nothing to do with future obsshelve introduction, done just for readability purposes.
Thu, 10 Nov 2016 03:07:20 -0800 shelve: move possible shelve file extensions to a single place
Kostia Balytskyi <ikostia@fb.com> [Thu, 10 Nov 2016 03:07:20 -0800] rev 30378
shelve: move possible shelve file extensions to a single place This and a couple of following patches are a preparation to implementing obsolescense-enabled shelve which was discussed on a Sprint. If this refactoring is not done, shelve is going to look even more hackish than now. This particular commit introduces a slight behavior change. Previously, if only .hg/shelve/name.patch file exists, but .hg/name.hg does not, 'hg shelve -d name' would fail saying "shelve not found". Now deletion will only fail if .patch file does not exist (since .patch is used as an indicator of an existing shelve). Other shelve files being absent are skipped silently to accommodate for future introduction of obs-based shelve, which will mean that for some shelves .hg and .patch files exist, while for others .hg and .oshelve.
Thu, 10 Nov 2016 02:13:19 -0800 manifest: delete manifest.manifest class
Durham Goode <durham@fb.com> [Thu, 10 Nov 2016 02:13:19 -0800] rev 30377
manifest: delete manifest.manifest class Now that nothing uses the primary manifest class, we can delete it.
Thu, 10 Nov 2016 02:13:19 -0800 localrepo: delete localrepo.manifest
Durham Goode <durham@fb.com> [Thu, 10 Nov 2016 02:13:19 -0800] rev 30376
localrepo: delete localrepo.manifest Now that nothing uses normal manifests, we can delete localrepo.manifest.
Thu, 10 Nov 2016 02:13:19 -0800 manifest: remove last uses of repo.manifest
Durham Goode <durham@fb.com> [Thu, 10 Nov 2016 02:13:19 -0800] rev 30375
manifest: remove last uses of repo.manifest Now that all the functionality has been moved to manifestlog/manifestrevlog/etc, we can finally change all the uses of repo.manifest to use the new versions. A future diff will then delete repo.manifest. One additional change in this commit is to change repo.manifestlog to be a @storecache property instead of @property. This is required by some uses of repo.manifest require that it be settable (contrib/perf.py and the static http server). We can't do this in a prior change because we can't use @storecache on this until repo.manifest is no longer used anywhere.
Fri, 11 Nov 2016 01:20:13 -0800 manifest: add unionmanifestlog support
Durham Goode <durham@fb.com> [Fri, 11 Nov 2016 01:20:13 -0800] rev 30374
manifest: add unionmanifestlog support As part of deprecating manifest, we need to make the union repo support manifestlog.
Fri, 11 Nov 2016 01:15:59 -0800 manifest: add bundlemanifestlog support
Durham Goode <durham@fb.com> [Fri, 11 Nov 2016 01:15:59 -0800] rev 30373
manifest: add bundlemanifestlog support As part of deprecating manifest.manifest we need to make bundlerepo support manifestlog.
(0) -30000 -10000 -3000 -1000 -300 -100 -50 -30 +30 +50 +100 +300 +1000 +3000 +10000 tip