Tue, 19 Jan 2016 15:37:07 -0800 shelve: use cg3 for treemanifests stable
Martin von Zweigbergk <martinvonz@google.com> [Tue, 19 Jan 2016 15:37:07 -0800] rev 27931
shelve: use cg3 for treemanifests Similar to previous change, this teaches shelve to pick the right changegroup version for repos that use treemanifests.
Tue, 19 Jan 2016 15:38:24 -0800 repair: use cg3 for treemanifests stable
Martin von Zweigbergk <martinvonz@google.com> [Tue, 19 Jan 2016 15:38:24 -0800] rev 27930
repair: use cg3 for treemanifests The newly created helper changegroup.safeversion() knows to pick version 03 if the repo uses treemanifests, so just using that means we pick the right changegroup version.
Tue, 19 Jan 2016 15:32:32 -0800 changegroup: introduce safeversion() stable
Martin von Zweigbergk <martinvonz@google.com> [Tue, 19 Jan 2016 15:32:32 -0800] rev 27929
changegroup: introduce safeversion() In a few places (at least repair.py and shelve.py), we want to find the best changegroup version that we can assume users of the repo will understand. For example, we choose version 01 by default, but if it's a generaldelta repo, we expect clients to support version 02 anyway, so we choose that for new bundles (for e.g. "hg strip"). Let's create a helper for this functionality in changegroup, so we can reuse it elsewhere later.
Tue, 19 Jan 2016 14:27:18 -0800 changegroup: don't support versions 01 and 02 with treemanifests stable
Martin von Zweigbergk <martinvonz@google.com> [Tue, 19 Jan 2016 14:27:18 -0800] rev 27928
changegroup: don't support versions 01 and 02 with treemanifests Since it would be terribly expensive to convert between flat manifests and treemanifests, we have decided to simply not support changegroup version 01 and 02 with treemanifests. Therefore, let's stop announcing that we support these versions on treemanifest repos. Note that this means that older clients that try to clone from a treemanifest repo will fail. What happens is that the server, after this patch, finds that there are no common versions and raises "ValueError: no common changegroup version". This results in "abort: HTTP Error 500: Internal Server Error" on the client. Before this patch, it was no better: The server would instead find that there were directory manifest nodes to put in the changegroup 01 or 02 and raise an AssertionError on changegroup.py#668 (assert not tmfnodes), which would also appear as a 500 to the client.
Tue, 19 Jan 2016 08:22:27 -0800 run-tests: fix crash when --json and --blacklist are both used (issue5050) stable
Laurent Charignon <lcharignon@fb.com> [Tue, 19 Jan 2016 08:22:27 -0800] rev 27927
run-tests: fix crash when --json and --blacklist are both used (issue5050) This patch fixes a crash when both --json and --blacklist were given as arguments of run-tests.py. Now, instead of crashing, we add an entry for blacklisted tests in the json output to show that the tests were skipped.
Thu, 21 Jan 2016 12:37:12 -0800 run-tests: fix race condition stable
Laurent Charignon <lcharignon@fb.com> [Thu, 21 Jan 2016 12:37:12 -0800] rev 27926
run-tests: fix race condition Before this patch, it was possible for run-tests to crash on a race condition. The race condition happens in the following case: - the last test finishes and calls: done.put(None) - the context switches to the main thread that clears the channels list - the context switches to the last test mentioned above, it tries to access channels[channel] and crashes This happened to me while running run-tests. This patch fixes the issue by clearing the channel before considering that the test is done.
Thu, 21 Jan 2016 21:15:52 +0000 copyright: update to 2016 stable
timeless <timeless@mozdev.org> [Thu, 21 Jan 2016 21:15:52 +0000] rev 27925
copyright: update to 2016
Tue, 19 Jan 2016 15:18:21 -0800 transaction: abort transaction during hook exception stable
Durham Goode <durham@fb.com> [Tue, 19 Jan 2016 15:18:21 -0800] rev 27924
transaction: abort transaction during hook exception The new transaction context did not handle the case where an exception during close should still call release. This cause pretxnclose hooks that failed to cause the transaction to fail without aborting, thus requiring a hg recover. I've added a test.
Wed, 20 Jan 2016 22:39:51 -0600 Added signature for changeset 158bdc896572 stable
Matt Mackall <mpm@selenic.com> [Wed, 20 Jan 2016 22:39:51 -0600] rev 27923
Added signature for changeset 158bdc896572
Wed, 20 Jan 2016 22:39:50 -0600 Added tag 3.7-rc for changeset 158bdc896572 stable
Matt Mackall <mpm@selenic.com> [Wed, 20 Jan 2016 22:39:50 -0600] rev 27922
Added tag 3.7-rc for changeset 158bdc896572
Thu, 21 Jan 2016 00:20:19 +0000 shelve: lowercase flag description stable 3.7-rc
timeless <timeless@mozdev.org> [Thu, 21 Jan 2016 00:20:19 +0000] rev 27921
shelve: lowercase flag description The help for --unknown is the *only* command that started with a capital letter
Tue, 19 Jan 2016 17:44:25 -0800 changegroup: cg3 has two empty groups *after* manifests stable
Martin von Zweigbergk <martinvonz@google.com> [Tue, 19 Jan 2016 17:44:25 -0800] rev 27920
changegroup: cg3 has two empty groups *after* manifests changegroup.getchunks() determines the end of the stream by looking for an empty chunk group (two consecutive empty chunks). It ignores empty groups in the first two groups. Changegroup 3 introduced an empty chunk between the manifests and the files, which confuses getchunks(). Since it comes after the first two, getchunks() will stop there. Fix by rewriting getchunks so it first counts two groups (empty or not) and then keeps antostarts counting empty groups. With this counting, changegroup 1 and 2 have exactly one empty group after the first two groups, while changegroup 3 has two (one for directories and one for files). It's a little hard to test this at this point, but I have verified that this patch fixes narrowhg (which was broken before this patch). Also, future patches will fix "hg strip" with treemanifests, and once that's done, getchunks() will be tested through tests of "hg strip".
Tue, 19 Jan 2016 06:00:59 +0100 mq: check for reserved patch name with qimport -r (issue5033) stable
Mads Kiilerich <madski@unity3d.com> [Tue, 19 Jan 2016 06:00:59 +0100] rev 27919
mq: check for reserved patch name with qimport -r (issue5033) Fix regression from 143b52fce68e. Catching aborts might not be pretty but it works and is a small change.
Tue, 19 Jan 2016 06:00:30 +0100 mq: refactor makepatchname into class method stable
Mads Kiilerich <madski@unity3d.com> [Tue, 19 Jan 2016 06:00:30 +0100] rev 27918
mq: refactor makepatchname into class method
Wed, 20 Jan 2016 13:43:01 -0800 repoview: fix corrupted hiddencache crash Mercurial (issue5042) stable
Laurent Charignon <lcharignon@fb.com> [Wed, 20 Jan 2016 13:43:01 -0800] rev 27917
repoview: fix corrupted hiddencache crash Mercurial (issue5042) Before this patch if the hiddencache existed but was empty, it would crash mercurial. This patch adds exception handling when reading the hiddencache to avoid the issue. When encountering a corrupted cache file we print a devel warning. There would be no point in issuing a normal warning as the user wouldn't be able to do anything about the situation. The warning looks like: devel-warn: corrupted hidden cache, removing it at: /path/to/repoview.py
Wed, 20 Jan 2016 13:40:59 -0800 repoview: add missing newline character in debug prints stable
Laurent Charignon <lcharignon@fb.com> [Wed, 20 Jan 2016 13:40:59 -0800] rev 27916
repoview: add missing newline character in debug prints
Wed, 20 Jan 2016 00:08:00 +0900 commandserver: drop tell() and seek() from channels (issue5049) stable
Yuya Nishihara <yuya@tcha.org> [Wed, 20 Jan 2016 00:08:00 +0900] rev 27915
commandserver: drop tell() and seek() from channels (issue5049) These operations are obviously invalid for file-like channels because they will read or write protocol headers. This patch works around the issue that "hg archive" generates a corrupted zip file on Windows commandserver because of unusable tell() implementation. But the problem still occurs without using a commandserver. $ hg archive -R not-small-repo -t zip - | cat > invalid.zip So, this patch cannot fix the issue5049 completely.
Wed, 20 Jan 2016 11:21:13 -0800 crecord: edit during hg crecord should preserve cursor position (issue5041) stable
Laurent Charignon <lcharignon@fb.com> [Wed, 20 Jan 2016 11:21:13 -0800] rev 27914
crecord: edit during hg crecord should preserve cursor position (issue5041) This patch adds a variable to keep track of what hunk was selected before the edit. We use that variable to select the hunk or its replacement after the edit.
Thu, 21 Jan 2016 02:42:01 +0900 templates: use canvaswidth instead of fixed width for canvas (issue2683) stable
FUJIWARA Katsunori <foozy@lares.dti.ne.jp> [Thu, 21 Jan 2016 02:42:01 +0900] rev 27913
templates: use canvaswidth instead of fixed width for canvas (issue2683) Before this patch, template files for "graph" web page use fixed width size "480" for canvas element. This causes pruned lanes and invisible vertexes, if there are 16 or more vertical lanes at once. In such case, part of graph in right side area over 480 is invisible, even though corresponded summary text blocks are visible correctly. This limitation isn't reasonable for workflow using many branches at once (e.g. "one branch per issue" workflow). There were changes below related to width of canvas: - 7359cb753a54 (templates: widen the graph canvas (issue2683)), released as a part of Mercurial 1.8.2 According to the description, this assumed that 15 parallel branches was enough for ordinary workflow, and bumped width of canvas up from 224 to 480. - d490edc71146 (hgweb: make graph data suitable for template usage), released as a part of Mercurial 2.3 This introduced "canvaswidth" template keyword as a part of refactoring around graph rendering. But 'width="480"' of canvas element in template files wasn't replaced by 'width="{canvaswidth}"' in it (or subsequent one). This patch uses dynamic value "{canvaswidth}" instead of fixed width size "480" for canvas element. This is posted for "stable", because: - this is re-fixing issue2683 - this is simple enough for stable - using "{canvaswidth}" doesn't require any additional cost Calculation of canvaswidth is already implied as a part of "graph" web command.
Wed, 20 Jan 2016 08:16:58 -0800 backout: fix --no-commit option (issue5054) stable
Ruslan Sayfutdinov <sayfutdinov@fb.com> [Wed, 20 Jan 2016 08:16:58 -0800] rev 27912
backout: fix --no-commit option (issue5054)
Tue, 19 Jan 2016 13:43:50 -0800 bundle: exit early when there are no commits to bundle stable
Durham Goode <durham@fb.com> [Tue, 19 Jan 2016 13:43:50 -0800] rev 27911
bundle: exit early when there are no commits to bundle Previously, if you passed a revset that resolved to no nodes, it would get interpreted by the changegroup discovery logic as 'bundle all my heads', which is not what the user asked. Let's exit early when we notice this case. It could be argued that the changeset discovery logic should be smarter and only assume 'all heads' if the incoming heads parameter is None, but that's a much riskier change.
Sun, 17 Jan 2016 20:37:29 -0800 zeroconf: access repo on hgweb_mod properly (issue5036) stable
Gregory Szorc <gregory.szorc@gmail.com> [Sun, 17 Jan 2016 20:37:29 -0800] rev 27910
zeroconf: access repo on hgweb_mod properly (issue5036) hgweb_mod.hgweb.repo disappeared in ae33fff17c1e (hg: establish a cache for localrepository instances) and the code for accessing repo instances from hgweb was later refactored to go through a cache-aware context manager. Adapt zeroconf to access the repo instance via the new API.
Sun, 17 Jan 2016 21:40:21 -0600 merge default into stable for 3.7 code freeze stable
Matt Mackall <mpm@selenic.com> [Sun, 17 Jan 2016 21:40:21 -0600] rev 27909
merge default into stable for 3.7 code freeze
Thu, 14 Jan 2016 10:03:31 -0800 shelve: permit shelves to contain unknown files
Simon Farnsworth <simonfar@fb.com> [Thu, 14 Jan 2016 10:03:31 -0800] rev 27908
shelve: permit shelves to contain unknown files If an emergency comes in while you're in the middle of an experimental change, it can be useful to shelve not just files hg already tracks but also your unknown files while you handle the emergency. This is especially true if you have hooks intended to prevent you from forgetting to add new code before you push. Teach "hg shelve" to optionally shelve unknown files, not just tracked files. This is functionally similar to --addremove, but with two differences: 1) Deleted files are not removed. 2) Files added during shelve creation are tracked in extra so that they can be forgotten by "hg unshelve". When unshelving, we take care to only forget files if they've been created during the unshelve operation; if you add a file that's being tracked in a shelve as an unknown file, it should not become unknown again when the shelve is unshelved.
Sun, 17 Jan 2016 14:14:15 -0800 localrepo: don't reference transaction from hook closure (issue5043)
Gregory Szorc <gregory.szorc@gmail.com> [Sun, 17 Jan 2016 14:14:15 -0800] rev 27907
localrepo: don't reference transaction from hook closure (issue5043) Before, the hook() closure (which is called as part of locking hooks) would maintain a reference to a transaction instance (which should be finalized by the time lock hooks are called). Because we accumulate hook() instances when there are multiple transactions per lock, this would result in holding references to the transaction instances which would lead to higher memory utilization. Creating a reference to the hook arguments dict minimizes the number of objects that are kept alive until the lock release hook runs, minimizing memory "leaks."
Sun, 17 Jan 2016 12:10:30 -0800 context: don't use util.cachefunc due to cycle creation (issue5043)
Gregory Szorc <gregory.szorc@gmail.com> [Sun, 17 Jan 2016 12:10:30 -0800] rev 27906
context: don't use util.cachefunc due to cycle creation (issue5043) util.cachefunc stores all arguments as the cache key. For filectxfn functions, the arguments include the memctx instance. This creates a cycle where memctx._filectxfn references self. This causes a memory leak. We break the cycle by implementing our own memoizing function that only uses the path as the cache key. Since each memctx has its own cache instance, there is no concern about invalid cache hits.
Sun, 17 Jan 2016 19:29:27 +0100 largefiles: actions will now always have a file - drop check
Mads Kiilerich <madski@unity3d.com> [Sun, 17 Jan 2016 19:29:27 +0100] rev 27905
largefiles: actions will now always have a file - drop check
Sun, 17 Jan 2016 19:29:27 +0100 largefiles: make prompt order deterministic
Mads Kiilerich <madski@unity3d.com> [Sun, 17 Jan 2016 19:29:27 +0100] rev 27904
largefiles: make prompt order deterministic 42ae1b1f048f introduced iteration of a set. Make it stable.
Sun, 17 Jan 2016 17:23:32 +0100 largefiles: fix commit of missing largefiles
Mads Kiilerich <madski@unity3d.com> [Sun, 17 Jan 2016 17:23:32 +0100] rev 27903
largefiles: fix commit of missing largefiles 832c98d79587 improved merging of standin files referencing missing largefiles. It did however not test or fix commits of such merges; it would abort. To fix that, change copytostore to skip and warn about missing largefiles with a message similar the one for failing get from remote filestores. (It would perhaps in both cases be better to emit a more helpful warning like "warning: standin file for large1 references 58e24f733a which can't be found in the local store".) To test this, make sure commit doesn't find the "missing" largefile in the global usercache. For further testing, verify that update and status works as expected after this. This will also effectively backout 63116d47cc3f.
Thu, 14 Jan 2016 10:22:55 -0800 diff: don't crash when merged-in addition is copied
Martin von Zweigbergk <martinvonz@google.com> [Thu, 14 Jan 2016 10:22:55 -0800] rev 27902
diff: don't crash when merged-in addition is copied Similar to what was explained in the previous commit, the diff code expected copy source to be in "ctx1", which is not always the case during a merge. This has been broken since before hg 2.0. Also similar to the previous commit, we fix the problem by fixing up the copy dict.
(0) -10000 -3000 -1000 -300 -100 -50 -30 +30 +50 +100 +300 +1000 +3000 +10000 tip