Sat, 08 Nov 2014 13:14:19 +0900 util.system: remove unused handling of onerr=ui
Yuya Nishihara <yuya@tcha.org> [Sat, 08 Nov 2014 13:14:19 +0900] rev 23271
util.system: remove unused handling of onerr=ui In our code, onerr is None or util.Abort. It smells bad to overload ui and exception class.
Sat, 08 Nov 2014 13:06:22 +0900 util.system: use ui.system() in place of optional ui.fout parameter
Yuya Nishihara <yuya@tcha.org> [Sat, 08 Nov 2014 13:06:22 +0900] rev 23270
util.system: use ui.system() in place of optional ui.fout parameter
Sat, 08 Nov 2014 12:57:42 +0900 ui: introduce util.system() wrapper to make sure ui.fout is used
Yuya Nishihara <yuya@tcha.org> [Sat, 08 Nov 2014 12:57:42 +0900] rev 23269
ui: introduce util.system() wrapper to make sure ui.fout is used This change is intended to avoid future problem of data corruption under command server. out=ui.fout is mandatory as long as command server uses stdout as IPC channel.
Wed, 12 Nov 2014 22:21:51 +0900 hook: remove redundant code to redirect http hook output to client stream
Yuya Nishihara <yuya@tcha.org> [Wed, 12 Nov 2014 22:21:51 +0900] rev 23268
hook: remove redundant code to redirect http hook output to client stream out=ui and out=ui.fout should be the same here. ui.fout was introduced at afccc64eea73, which was not available when out=ui was added at c37f35d7f2f5.
Wed, 12 Nov 2014 21:53:44 +0900 hgk: forward command output to ui.fout consistently
Yuya Nishihara <yuya@tcha.org> [Wed, 12 Nov 2014 21:53:44 +0900] rev 23267
hgk: forward command output to ui.fout consistently Nobody would want to run hgk in command server, but it should work in principle. This fixes possible data corruption of command-server channel.
Tue, 11 Nov 2014 18:43:19 -0600 merge with stable
Matt Mackall <mpm@selenic.com> [Tue, 11 Nov 2014 18:43:19 -0600] rev 23266
merge with stable
Tue, 11 Nov 2014 17:25:09 -0600 Added signature for changeset 643c58303fb0 stable
Matt Mackall <mpm@selenic.com> [Tue, 11 Nov 2014 17:25:09 -0600] rev 23265
Added signature for changeset 643c58303fb0
Tue, 11 Nov 2014 17:24:47 -0600 Added tag 3.2.1 for changeset 643c58303fb0 stable
Matt Mackall <mpm@selenic.com> [Tue, 11 Nov 2014 17:24:47 -0600] rev 23264
Added tag 3.2.1 for changeset 643c58303fb0
Mon, 10 Nov 2014 13:20:56 -0500 run-tests: use a try/except ladder instead of looking for a specific version
Augie Fackler <raf@durin42.com> [Mon, 10 Nov 2014 13:20:56 -0500] rev 23263
run-tests: use a try/except ladder instead of looking for a specific version This ensures we get json instead of simplejson in as many places as possible.
Mon, 10 Nov 2014 13:27:25 -0500 hghave: use a less brittle have-json check
Augie Fackler <raf@durin42.com> [Mon, 10 Nov 2014 13:27:25 -0500] rev 23262
hghave: use a less brittle have-json check
Wed, 15 Oct 2014 12:39:19 -0700 sortdict: add insert method
Sean Farley <sean.michael.farley@gmail.com> [Wed, 15 Oct 2014 12:39:19 -0700] rev 23261
sortdict: add insert method Future patches will allow extensions to choose which order a namespace should output in the log, so we add a way for sortdict to insert to a specific location.
Sun, 09 Nov 2014 13:15:28 -0800 sortdict: add iteritems method
Sean Farley <sean.michael.farley@gmail.com> [Sun, 09 Nov 2014 13:15:28 -0800] rev 23260
sortdict: add iteritems method Future patches will start using sortdict for log operations where order is important. Adding iteritems removes the headache of having to remember to use items() if the object is a sortdict.
Sat, 08 Nov 2014 23:13:39 -0800 addremove: add back forgotten files (BC)
Martin von Zweigbergk <martinvonz@google.com> [Sat, 08 Nov 2014 23:13:39 -0800] rev 23259
addremove: add back forgotten files (BC) After running "hg forget README && hg addremove", README will still be reported as removed, while "hg forget README && hg add README" adds it back so it gets reported as clean. It seems like they should behave the same. Furthermore, it seems like no files should remain untracked after 'hg addremove && hg commit' (or 'hg commit -A'). For these reasons, change the behavior of addremove so it does add forgotten files back. The problem is with scmutil._interestingfiles(), which reports the file as removed, so scmutil.addremove() does not add it. Fix by teaching _interestingfiles() to report forgotten files separately from removed files and make addremove() add forgotten files back. However, do not treat forgotten files as sources for rename detection. Note that since removed and forgotten files are treated the same before this change, forgotten files were considered sources for rename detection. Also update the other caller, marktouched(), in the same way as addremove().
Mon, 10 Nov 2014 14:51:18 -0800 add: add back forgotten files even when not matching exactly (BC)
Martin von Zweigbergk <martinvonz@google.com> [Mon, 10 Nov 2014 14:51:18 -0800] rev 23258
add: add back forgotten files even when not matching exactly (BC) I accidentally did 'hg forget .' and tried to undo the operation with 'hg add .'. I expected the files to be reported as either modified or clean, but they were still reported as removed. It turns out that forgotten files are only added back if they are listed explicitly, as shown by the following two invocations. This makes it hard to recover from the mistake of forgetting a lot of files. $ hg forget README && hg add README && hg status -A README C README $ hg forget README && hg add . && hg status -A README R README The problem lies in cmdutil.add(). That method checks that the file isn't already tracked before adding it, but it does so by checking the dirstate, which does have an entry for forgotten files (state 'r'). We should instead be checking whether the file exists in the workingctx. The workingctx is also what we later call add() on, and that method takes care of transforming the add() into a normallookup() on the dirstate. Since we're changing repo.dirstate into wctx, let's also change repo.walk into wctx.walk for consistency (repo.walk calls wctx.walk, so we're simply inlining the call).
Tue, 11 Nov 2014 10:16:54 -0800 context.status: explain "caching reasons" more fully
Martin von Zweigbergk <martinvonz@google.com> [Tue, 11 Nov 2014 10:16:54 -0800] rev 23257
context.status: explain "caching reasons" more fully Where we "load earliest manifest first for caching reasons", elaborate on what "caching reasons" refers to. Text provided by Matt in http://thread.gmane.org/gmane.comp.version-control.mercurial.devel/73235/focus=73578.
Tue, 11 Nov 2014 10:35:06 -0500 localrepo: rename revlog.maxchainlen to format.maxchainlen
Augie Fackler <raf@durin42.com> [Tue, 11 Nov 2014 10:35:06 -0500] rev 23256
localrepo: rename revlog.maxchainlen to format.maxchainlen This is more consistent with other option names, as spotted by Pierre-Yves. Thanks!
Thu, 06 Nov 2014 14:20:05 -0800 revlog: add config variable for limiting delta-chain length
Mateusz Kwapich <mitrandir@fb.com> [Thu, 06 Nov 2014 14:20:05 -0800] rev 23255
revlog: add config variable for limiting delta-chain length The current heuristic for deciding between storing delta and full texts is based on ratio of (sizeofdeltas)/(sizeoffulltext). In some cases (for example a manifest for ahuge repo) this approach can result in extremely long delta chains (~30,000) which are very slow to read. (In the case of a manifest ~500ms are added to every hg command because of that). This commit introduces "revlog.maxchainlength" configuration variable that will limit delta chain length.
Thu, 06 Nov 2014 14:08:25 -0800 debugrevlog: fix computing chain length in debugrevlog -d
Mateusz Kwapich <mitrandir@fb.com> [Thu, 06 Nov 2014 14:08:25 -0800] rev 23254
debugrevlog: fix computing chain length in debugrevlog -d The chain length was computed correctly only when generaldelta feature was enabled. Now it's fixed. When generaldelta is disabled the base revision in revlog index is not the revision we have delta against - it's always previous revision. Instead of incorrect chainbaseandlen in command.py we are now using two single-responsibility functions in revlog.py: - chainbase(rev) - chainlen(rev) Only chainlen(rev) was missing so it was written to mimic the way the chain of deltas is actually found during file reconstruction.
Wed, 05 Nov 2014 10:13:01 +0000 transaction: factorise append-only file registration
Pierre-Yves David <pierre-yves.david@fb.com> [Wed, 05 Nov 2014 10:13:01 +0000] rev 23253
transaction: factorise append-only file registration The addition is done in two different places but differs slightly. We factorise this addition to ensure it is consistent in all places.
Wed, 05 Nov 2014 13:00:48 +0000 transaction: document `tr.add`
Pierre-Yves David <pierre-yves.david@fb.com> [Wed, 05 Nov 2014 13:00:48 +0000] rev 23252
transaction: document `tr.add`
Wed, 05 Nov 2014 10:05:38 +0000 transaction: drop backupentries logic from startgroup and endgroup
Pierre-Yves David <pierre-yves.david@fb.com> [Wed, 05 Nov 2014 10:05:38 +0000] rev 23251
transaction: drop backupentries logic from startgroup and endgroup The `startgroup` and `endgroup` methods are used in a very specific context to wrap a very specific operation (revlog truncation). It does not make sense to perform any other operations during such a "group" (eg:file backup). There is currently no user of backupfile during a "group" so we drop the group-specific code and restrict authorized operations during "group".
Wed, 05 Nov 2014 10:00:15 +0000 transaction: document startgroup and endgroup
Pierre-Yves David <pierre-yves.david@fb.com> [Wed, 05 Nov 2014 10:00:15 +0000] rev 23250
transaction: document startgroup and endgroup These enigmatic methods are only used in repair. We document them to clarify there purpose and user.
Wed, 05 Nov 2014 09:31:57 +0000 transaction: mark backup-related attributes private
Pierre-Yves David <pierre-yves.david@fb.com> [Wed, 05 Nov 2014 09:31:57 +0000] rev 23249
transaction: mark backup-related attributes private As the transaction is gaining more functions and attributes, it is important to clarify what is part of the public API.
Wed, 05 Nov 2014 01:30:29 +0000 transaction: document the contents of `tr.backupentries`
Pierre-Yves David <pierre-yves.david@fb.com> [Wed, 05 Nov 2014 01:30:29 +0000] rev 23248
transaction: document the contents of `tr.backupentries` Now that all items are known we can document it.
Wed, 05 Nov 2014 01:33:16 +0000 transaction: drop the third item in `tr.backupentries`
Pierre-Yves David <pierre-yves.david@fb.com> [Wed, 05 Nov 2014 01:33:16 +0000] rev 23247
transaction: drop the third item in `tr.backupentries` This third item is always None and never used.
Mon, 10 Nov 2014 10:44:42 -0800 rebase: fix rebase with no common ancestors (issue4446) stable 3.2.1
Durham Goode <durham@fb.com> [Mon, 10 Nov 2014 10:44:42 -0800] rev 23246
rebase: fix rebase with no common ancestors (issue4446) The new rebase revset didn't check for the case when there are no common ancestors. Now it does. The new behavior should be the same as the pre-3.2 behavior. Added a test.
Thu, 06 Nov 2014 10:57:13 -0500 test-run-tests: accept more levels of precision and trailing ws (issue4440) stable
Augie Fackler <raf@durin42.com> [Thu, 06 Nov 2014 10:57:13 -0500] rev 23245
test-run-tests: accept more levels of precision and trailing ws (issue4440) simplejson produces slightly different output from the built-in json module, specifically: * It uses 0.000 instead of 0.0000 * It likes to put a trailing space after a comma This change works around both of those variations.
Mon, 10 Nov 2014 17:29:15 -0600 merge with stable
Matt Mackall <mpm@selenic.com> [Mon, 10 Nov 2014 17:29:15 -0600] rev 23244
merge with stable
Fri, 07 Nov 2014 17:54:59 -0800 changegroup.cg2packer: lookup 'group' via inheritance chain
Siddharth Agarwal <sid0@fb.com> [Fri, 07 Nov 2014 17:54:59 -0800] rev 23243
changegroup.cg2packer: lookup 'group' via inheritance chain This lets extensions insert themselves in the class hierarchy.
Thu, 23 Oct 2014 17:00:38 -0700 context.status: only filter suspect symlinks in the dirstate status
Martin von Zweigbergk <martinvonz@google.com> [Thu, 23 Oct 2014 17:00:38 -0700] rev 23242
context.status: only filter suspect symlinks in the dirstate status We don't care about filtering out symlinks that have already been committed with full content, only those that have been accidentally resolved in the working directory.
(0) -10000 -3000 -1000 -300 -100 -50 -30 +30 +50 +100 +300 +1000 +3000 +10000 tip