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.
(0) -10000 -3000 -1000 -300 -100 -10 +10 +100 +300 +1000 +3000 +10000 tip