Mon, 22 Dec 2014 17:27:31 -0500 demandimport: blacklist distutils.msvc9compiler (issue4475) stable
Augie Fackler <raf@durin42.com> [Mon, 22 Dec 2014 17:27:31 -0500] rev 23643
demandimport: blacklist distutils.msvc9compiler (issue4475) This module depends on _winreg, which is windows-only. Recent versions of setuptools load distutils.msvc9compiler and expect it to ImportError immediately when on non-Windows platforms, so we need to let them do that. This breaks in an especially mystifying way, because setuptools uses vars() on the imported module. We then throw an exception, which vars doesn't pick up on well. For example: In [3]: class wat(object): ...: @property ...: def __dict__(self): ...: assert False ...: In [4]: vars(wat()) --------------------------------------------------------------------------- TypeError Traceback (most recent call last) <ipython-input-4-2781ada5ffe6> in <module>() ----> 1 vars(wat()) TypeError: vars() argument must have __dict__ attribute Which is similar to the problem we run into.
Thu, 11 Dec 2014 22:51:29 -0800 largefiles: don't duplicate 'actions' into 'actionbyfile'
Martin von Zweigbergk <martinvonz@google.com> [Thu, 11 Dec 2014 22:51:29 -0800] rev 23642
largefiles: don't duplicate 'actions' into 'actionbyfile'
Thu, 11 Dec 2014 22:07:41 -0800 merge: make calculateupdates() return file->action dict
Martin von Zweigbergk <martinvonz@google.com> [Thu, 11 Dec 2014 22:07:41 -0800] rev 23641
merge: make calculateupdates() return file->action dict This simplifies largefiles' overridecalculateupdates(), which no longer has to do the conversion it started doing in 38e55e55ae4d (largefiles: rewrite merge code using dictionary with entry per file, 2014-12-09). To keep this patch small, we'll leave the name 'actionbyfile' in overrides.py. It will be renamed in the next patch.
Thu, 11 Dec 2014 21:58:49 -0800 merge: let _forgetremoved() work on the file->action dict
Martin von Zweigbergk <martinvonz@google.com> [Thu, 11 Dec 2014 21:58:49 -0800] rev 23640
merge: let _forgetremoved() work on the file->action dict By moving the conversion from the file->action dict after _forgetremoved(), we make that method shorter by removing the need for the confusing 'xactions' variable.
Thu, 11 Dec 2014 21:06:16 -0800 merge: let _resolvetrivial() work on the file->action dict
Martin von Zweigbergk <martinvonz@google.com> [Thu, 11 Dec 2014 21:06:16 -0800] rev 23639
merge: let _resolvetrivial() work on the file->action dict By moving the conversion from the file->action dict after _resolvetrivial(), we greatly simplify and clarify that method.
Thu, 11 Dec 2014 20:56:53 -0800 merge: let bid merge work on the file->action dict
Martin von Zweigbergk <martinvonz@google.com> [Thu, 11 Dec 2014 20:56:53 -0800] rev 23638
merge: let bid merge work on the file->action dict By moving the conversion from the file->action dict after the bid merge code, bid merge can be simplified a little. A few tests are affected by this change. Where we used to iterate over the actions first in order of the action type ('g', 'r', etc.) [1], we now iterate in order of filename. This difference affects the order of debug log statements. [1] And then in the non-deterministic order of files in the manifest dictionary (the order returned from manifest.diff()).
Mon, 08 Dec 2014 13:24:10 -0800 merge: write manifestmerge() using dictionary with entry per file
Martin von Zweigbergk <martinvonz@google.com> [Mon, 08 Dec 2014 13:24:10 -0800] rev 23637
merge: write manifestmerge() using dictionary with entry per file In the same vein as 38e55e55ae4d (largefiles: rewrite merge code using dictionary with entry per file, 2014-12-09), rewrite manifestmerge() itself as dictionary with the filename as key. This will let us simplify some of the other code in merge.py and eventually drop the conversion in the largefiles code. No difference in speed could be detected (well within the noise level when run in Mozilla repo).
Wed, 17 Dec 2014 12:21:07 -0800 repoview: backout ced3ecfc2e57
Pierre-Yves David <pierre-yves.david@fb.com> [Wed, 17 Dec 2014 12:21:07 -0800] rev 23636
repoview: backout ced3ecfc2e57 Monkey patching repoview does not really work and making it really work will be really hard. So we better have it broken without complexity than broken with extra complexity.
Wed, 17 Dec 2014 12:19:33 -0800 largefile: explain why no monkey patching on a repoview
Pierre-Yves David <pierre-yves.david@fb.com> [Wed, 17 Dec 2014 12:19:33 -0800] rev 23635
largefile: explain why no monkey patching on a repoview The comment requested for investigations, here they are.
Wed, 17 Dec 2014 12:10:16 -0800 largefile: backout ca54fb3d71ce
Pierre-Yves David <pierre-yves.david@fb.com> [Wed, 17 Dec 2014 12:10:16 -0800] rev 23634
largefile: backout ca54fb3d71ce The hack for method monkey patching on repoview has been ruled out as fragile, so we are rolling it back. We'll expand the explanation in the next changeset.
Thu, 18 Dec 2014 12:33:17 -0800 incoming: handle phases the same as pull
Eric Sumner <ericsumner@fb.com> [Thu, 18 Dec 2014 12:33:17 -0800] rev 23633
incoming: handle phases the same as pull Now that bundlerepo can move phases safely, 'hg incoming' can share its phase handling code with pull to better reflect what would actually show up.
Thu, 18 Dec 2014 12:22:43 -0800 bundlerepo: retract phase boundary
Eric Sumner <ericsumner@fb.com> [Thu, 18 Dec 2014 12:22:43 -0800] rev 23632
bundlerepo: retract phase boundary This patch makes bundrepo retract the phase boundary for new commits to 'draft' status, which is consistent with the behavior of 'hg unbundle'. The old behavior was for commits to appear with the same phase as their nearest ancestor in the base repository. This affects several classes of operation: * Inspecting a bundle with the -B flag * Treating a bundle file as a peer (old: everything public, new: everything draft) * Incoming command (neither old or new behavior is sensible -- fixed in next patch)
Thu, 18 Dec 2014 11:38:48 -0800 bundlerepo: implement safe phasecache
Eric Sumner <ericsumner@fb.com> [Thu, 18 Dec 2014 11:38:48 -0800] rev 23631
bundlerepo: implement safe phasecache This patch makes bundlerepo use a subclass of phasecache that will allow phase boundaries to be moved around, but will never write them to the underlying repository.
Thu, 18 Dec 2014 11:30:10 -0800 localrepo.__getitem__: add slicing support
Eric Sumner <ericsumner@fb.com> [Thu, 18 Dec 2014 11:30:10 -0800] rev 23630
localrepo.__getitem__: add slicing support This allows the python slice syntax to be used with revision numbers when indexing into a repository, such as repo[8:]
Tue, 16 Dec 2014 14:34:53 -0800 ignore: resolve ignore files relative to repo root (issue4473) (BC)
Siddharth Agarwal <sid0@fb.com> [Tue, 16 Dec 2014 14:34:53 -0800] rev 23629
ignore: resolve ignore files relative to repo root (issue4473) (BC) Previously these would be considered to be relative to the current working directory. That behavior is both undocumented and doesn't really make sense. There are two reasonable options for how to resolve relative paths: - relative to the repo root - relative to the config file Resolving these files relative to the repo root matches existing behavior with hooks. An earlier discussion about this is available at http://mercurial.markmail.org/thread/tvu7yhzsiywgkjzl. Thanks to Isaac Jurado <diptongo@gmail.com> for the initial patchset that spurred the discussion.
Wed, 17 Dec 2014 18:53:38 -0800 test-hgignore: add testing for ui.ignore
Siddharth Agarwal <sid0@fb.com> [Wed, 17 Dec 2014 18:53:38 -0800] rev 23628
test-hgignore: add testing for ui.ignore I couldn't find any tests for this, and we're going to make changes here in upcoming patches.
Wed, 10 Dec 2014 22:09:46 -0500 tests: add missing globs for Windows
Matt Harbison <matt_harbison@yahoo.com> [Wed, 10 Dec 2014 22:09:46 -0500] rev 23627
tests: add missing globs for Windows I couldn't figure out how to glob the first chunk for Windows, so it's been conditionalized.
Thu, 18 Dec 2014 23:24:17 -0500 share: use the 'sharedpath' attr on repo instead of reloading from the file
Matt Harbison <matt_harbison@yahoo.com> [Thu, 18 Dec 2014 23:24:17 -0500] rev 23626
share: use the 'sharedpath' attr on repo instead of reloading from the file Seems like a useful optimization, and now the exact file content is not a concern.
Thu, 18 Dec 2014 23:16:37 -0500 share: fix source repo lookup on Windows
Matt Harbison <matt_harbison@yahoo.com> [Thu, 18 Dec 2014 23:16:37 -0500] rev 23625
share: fix source repo lookup on Windows The stored path contains platform specific separators, so splitting on '/.hg' returned the string unmodified on Windows. The source was then looked for in $source/.hg/.hg, which obviously fails. This caused cascading errors in test-share.t relating to the recent bookmark support.
Mon, 22 Dec 2014 03:20:50 +0100 help: suggest '-v -e' to get built-in aliases for extensions (issue4461)
Chingis Dugarzhapov <chingis.dug@gmail.com> [Mon, 22 Dec 2014 03:20:50 +0100] rev 23624
help: suggest '-v -e' to get built-in aliases for extensions (issue4461) If extension name matches one of command names, suggest user to type 'hg help -v -e <extension>' to get full list of built-in aliases
Thu, 18 Dec 2014 10:11:38 -0800 test-check-commit-hg: clarify misleading "commit message rules" error
Martin von Zweigbergk <martinvonz@google.com> [Thu, 18 Dec 2014 10:11:38 -0800] rev 23623
test-check-commit-hg: clarify misleading "commit message rules" error The test case doesn't only check the commit message, but also the patch, which can result in confusing output like + Revision df6f06d17100 does not comply to commit message rules + ------------------------------------------------------ + 32: adds double empty line + + even when there are no double blank lines in the commit message. Drop the "commit message" part to make it less confusing.
Sun, 21 Dec 2014 13:02:59 +0000 keyword: handle resolve to either parent
Christian Ebert <blacktrash@gmx.net> [Sun, 21 Dec 2014 13:02:59 +0000] rev 23622
keyword: handle resolve to either parent Merged files are considered modified at commit time even if only 1 parent differs. In this case we must use the change context of this parent for expansion. The issue went unnoticed for long because it is only apparent until the next update to the merge revision - except in test-keyword where it was always staring us in the face.
Sun, 21 Dec 2014 12:53:57 +0000 keyword: update test file syntax
Christian Ebert <blacktrash@gmx.net> [Sun, 21 Dec 2014 12:53:57 +0000] rev 23621
keyword: update test file syntax
Mon, 22 Dec 2014 14:49:05 -0600 branches: deprecate -a
Matt Mackall <mpm@selenic.com> [Mon, 22 Dec 2014 14:49:05 -0600] rev 23620
branches: deprecate -a
Sun, 21 Dec 2014 15:06:54 -0500 largefiles: fix a spurious missing file warning with forget (issue4053) stable
Matt Harbison <matt_harbison@yahoo.com> [Sun, 21 Dec 2014 15:06:54 -0500] rev 23619
largefiles: fix a spurious missing file warning with forget (issue4053) If an uncommitted and deleted file was forgotten, a warning would be emitted, even though the operation was successful. See the previous patch for 'remove -A' for the exact circumstances, and details about the cause.
Sun, 21 Dec 2014 15:04:13 -0500 largefiles: fix a spurious missing file warning with 'remove -A' (issue4053) stable
Matt Harbison <matt_harbison@yahoo.com> [Sun, 21 Dec 2014 15:04:13 -0500] rev 23618
largefiles: fix a spurious missing file warning with 'remove -A' (issue4053) The bug report doesn't mention largefiles, but the given recipe doesn't fail unless the largefiles extension is loaded. The problem only affected normal files, whether or not any largefiles are committed, and only files that have not been committed yet. (Files with an 'a' state are dropped from dirstate, not marked removed.) Further, if the named normal file never existed, the warning would be printed out twice. The problem is that the core implementation of remove() calls repo.status(), which eventually triggers a dirstate.walk(). When the file isn't seen in the filesystem during the walk, the exception handling finds the file in dirstate, so it doesn't complain. However, the largefiles implementation called status() again with all of the original files (including the normal ones, just dropped). This time, the exception handler doesn't find the file in dirstate and does complain. This simply excludes the normal files from the second repo.status() call, which the largefiles extension has no interest is processing anyway.
Sun, 21 Dec 2014 14:42:46 -0500 largefiles: introduce the 'composelargefilematcher()' method stable
Matt Harbison <matt_harbison@yahoo.com> [Sun, 21 Dec 2014 14:42:46 -0500] rev 23617
largefiles: introduce the 'composelargefilematcher()' method This is a copy/paste (with the necessary tweaks) of the composenormalfilematcher method currently on default, which does the inverse- this trims the normal files out of the matcher. It will be used in the next patch.
Thu, 18 Dec 2014 09:37:14 -0800 context: return dirstate parents in workingctx.ancestors()
Durham Goode <durham@fb.com> [Thu, 18 Dec 2014 09:37:14 -0800] rev 23616
context: return dirstate parents in workingctx.ancestors() workingctx.ancestors() was not returning the dirstate parents as part of the result set. The only place this function is used is for copy detection when committing a file, and that code already checks the parents manually, so this change has no affect at the moment. I found it while playing around with changing how copy detection works.
Wed, 17 Dec 2014 17:26:12 -0800 backout: add --commit option
Mateusz Kwapich <mitrandir@fb.com> [Wed, 17 Dec 2014 17:26:12 -0800] rev 23615
backout: add --commit option Mercurial backout command makes a commmit by default only when the backed out revision is the parent of working directory and doesn't commit in any other case. The --commit option changes behaviour of backout to make a commit whenever possible (i.e. there is no unresolved conflicts). This behaviour seems more intuitive to many use (especially git users migrating to hg).
Sat, 13 Dec 2014 11:32:46 -0800 share: add option to share bookmarks
Ryan McElroy <rmcelroy@fb.com> [Sat, 13 Dec 2014 11:32:46 -0800] rev 23614
share: add option to share bookmarks This patch adds the -B/--bookmarks option to the share command added by the share extension. All it does for now is create a marker, 'bookmarks.shared', that will be used by future code to implement the sharing functionality.
(0) -10000 -3000 -1000 -300 -100 -50 -30 +30 +50 +100 +300 +1000 +3000 +10000 tip