Tue, 23 Feb 2016 10:59:25 -0800 merge: use any() instead of for loop when checking for dirty subrepos
Martin von Zweigbergk <martinvonz@google.com> [Tue, 23 Feb 2016 10:59:25 -0800] rev 28226
merge: use any() instead of for loop when checking for dirty subrepos I think it's both simpler and clearer to use any() than the current for loop. While at it, also drop the call to sorted(), since it doesn't matter which order we iterate over subrepos.
Wed, 24 Feb 2016 19:31:55 +0000 templater: fix list templating bug
Kostia Balytskyi <ikostia@fb.com> [Wed, 24 Feb 2016 19:31:55 +0000] rev 28225
templater: fix list templating bug High-level use case: printing a list of objects with formatter when each object in turn contains a list of properties (like when % template symbol is used in {things % '{thing}'} Let the top-level list contain one thing with two properties: objs = [{ 'props': [ { 'value': 1, 'show': 1 }, { 'value': 2 }] }] (please note that second property does not have 'show' key) If a templateformatter is used to print this with template "{props % '{if(show, value)}'}" current implementation will print value for both properties, which is a bug. This happens because in `templater.runmap` function we only rewrite mapping values with existing new values for each item. If some mapping value is missing in the item, it will not be removed.
Wed, 24 Feb 2016 16:58:07 +0100 histedit: also handle locally missing nodes when reading obsolescence
Pierre-Yves David <pierre-yves.david@fb.com> [Wed, 24 Feb 2016 16:58:07 +0100] rev 28224
histedit: also handle locally missing nodes when reading obsolescence The previous version of the code was interpreting markers to a missing node as a prune in all cases. The expected way to handle such situation is to keep reading markers, only turning successors into "prune" if they are at the end of a chain. We update the code and add a test for this.
Wed, 24 Feb 2016 18:42:59 +0000 chgserver: auto exit after being idle for too long or lose the socket file
Jun Wu <quark@fb.com> [Wed, 24 Feb 2016 18:42:59 +0000] rev 28223
chgserver: auto exit after being idle for too long or lose the socket file This is a part of the one server per config series. In multiple-server setup, new server may be started for a temporary config change like in command line, --config extensions.foo=bar.py. This may end up with a lot of not so useful server processes. Other questions are about socket file and process management, How to stop these processes? What if a new server wants to listen on a same address, replacing the old one? This patch introduces AutoExitMixIn, which will: 1. Exit after being idle for too long. So useless servers won't run forever. 2. Periodically check the ownership of socket file, exit if it is no longer owned. This brings strong consistency between the filesystem and the process, and handles some race conditions neatly. Since rename is atomic, a new server can just have a same server address with an old one and won't worry about how to make sure the old server is killed, address conflict, service downtime issues. The user can safely stop all servers by simply removing the socket files, without worrying about outdated or accidentally removed pidfiles.
Mon, 22 Feb 2016 23:36:04 +0100 unionrepo: properly handle hidden linkrev in revlog (issue5070) stable
Pierre-Yves David <pierre-yves.david@fb.com> [Mon, 22 Feb 2016 23:36:04 +0100] rev 28222
unionrepo: properly handle hidden linkrev in revlog (issue5070) The unionrepository have to do some special magic to handle linkrev of the unioned filerev and manifestrev. That logic was done from a repoview and obsolescence marker affecting bundled changeset could lead to a crash. We now ensure we operate on unfiltered repository.
Mon, 22 Feb 2016 23:34:54 +0100 bundlerepo: properly handle hidden linkrev in manifestlog (issue4945) stable
Pierre-Yves David <pierre-yves.david@fb.com> [Mon, 22 Feb 2016 23:34:54 +0100] rev 28221
bundlerepo: properly handle hidden linkrev in manifestlog (issue4945) The bundlerepository have to do some special magic to handle linkrev of the bundled manifest. That logic was done from a repoview and obsolescence marker affecting bundled changeset could lead to a crash. We now ensure we operate on unfiltered repository.
Mon, 22 Feb 2016 18:35:40 +0100 bundlerepo: properly handle hidden linkrev in filelog (issue4945) stable
Pierre-Yves David <pierre-yves.david@fb.com> [Mon, 22 Feb 2016 18:35:40 +0100] rev 28220
bundlerepo: properly handle hidden linkrev in filelog (issue4945) The bundlerepository have to do some special magic to handle linkrev of the bundlerepo filerev. That logic was done from a repoview and obsolescence marker affecting bundled changeset could lead to a crash. We now ensure we operate on unfiltered repository.
(0) -10000 -3000 -1000 -300 -100 -30 -10 -7 +7 +10 +30 +100 +300 +1000 +3000 +10000 tip