Tue, 07 Jan 2014 22:29:57 +0100 check-code: print debug output when an ignore pattern matches
Simon Heimberg <simohe@besonet.ch> [Tue, 07 Jan 2014 22:29:57 +0100] rev 20243
check-code: print debug output when an ignore pattern matches
Tue, 07 Jan 2014 22:29:51 +0100 check-code: drop now unused check-code-ignore
Simon Heimberg <simohe@besonet.ch> [Tue, 07 Jan 2014 22:29:51 +0100] rev 20242
check-code: drop now unused check-code-ignore Using check-code-ignore to skip the failures on a line has several disadvantages: * It skips all check-code failures on a line, not only the one it was created for. * It does not give any hint for which rule it was added, making it difficult to see when it is not needed anymore. So drop this pragma in favor of better alternatives promoted before.
Tue, 07 Jan 2014 22:29:44 +0100 check-code: explain what to do when a check-code rule mismatches
Simon Heimberg <simohe@besonet.ch> [Tue, 07 Jan 2014 22:29:44 +0100] rev 20241
check-code: explain what to do when a check-code rule mismatches In the past several approaches were used when a check-code rule triggered without a good reason. Not all of them looked nice, some were even wrong. Suggest some good practices which should be used instead.
Tue, 07 Jan 2014 22:29:39 +0100 cleanup: Remove the only ever used skip-check-code pragma
Simon Heimberg <simohe@besonet.ch> [Tue, 07 Jan 2014 22:29:39 +0100] rev 20240
cleanup: Remove the only ever used skip-check-code pragma Use the work-around suggested by the rule instead
Tue, 07 Jan 2014 22:29:15 +0100 check-code: always report when a file is skipped by "no-check-code"
Simon Heimberg <simohe@besonet.ch> [Tue, 07 Jan 2014 22:29:15 +0100] rev 20239
check-code: always report when a file is skipped by "no-check-code" Skipping an entire file generally from checking is an important event, so report it always. Do not tell the check name because skipping does not depend on it. Directly skip the entire file instead of checking more patterns and skip again. The pragma no-check-code was introduced by accident in the past. (Fixed in e033a7d444ac and ee07f9d142c9.) This now is prevented because the files to skip have to be listed in the test output of test-check-code-hg.t.
Tue, 07 Jan 2014 22:28:45 +0100 check-code: do not skip entire file, skip only one match instead
Simon Heimberg <simohe@besonet.ch> [Tue, 07 Jan 2014 22:28:45 +0100] rev 20238
check-code: do not skip entire file, skip only one match instead Skipping of the entire file has been introduced in bc3b48b0f5c8.
Sat, 16 Nov 2013 15:46:29 -0500 bisect: --command without --noupdate should flag the parent rev it tested
Mads Kiilerich <madski@unity3d.com> [Sat, 16 Nov 2013 15:46:29 -0500] rev 20237
bisect: --command without --noupdate should flag the parent rev it tested 14913fcb30c6 not only introduced the 'bisect(current)' revset predicate, it also changed how the 'current' revision is used in combination with --command. The new behaviour might be ok for --noupdate where the working directory and its revision shouldn't be used, but it also did that when --command is used to run a command on the currently checked out revision then it could register the test result on the wrong revision. An example: Before, bisect with --command could use the wrong revision when recording the test result: $ hg up -qr 0 $ hg bisect --command "python \"$TESTTMP/script.py\" and some parameters" changeset 31:58c80a7c8a40: bad abort: inconsistent state, 31:58c80a7c8a40 is good and bad Now it works as before and as expected and uses the working directory revision for the --command result: $ hg up -qr 0 $ hg bisect --command "python \"$TESTTMP/script.py\" and some parameters" changeset 0:b99c7b9c8e11: bad ...
Sat, 16 Nov 2013 15:46:29 -0500 context: drop caching 'copies' method
Mads Kiilerich <madski@unity3d.com> [Sat, 16 Nov 2013 15:46:29 -0500] rev 20236
context: drop caching 'copies' method The 'copies' method has no test coverage and calls copies.pathcopies with an incorrect number of parameters and is thus (fortunately) not used. Kill it.
Tue, 19 Nov 2013 12:43:29 -0800 commands.bookmarks: move hexfn to inside list block
Siddharth Agarwal <sid0@fb.com> [Tue, 19 Nov 2013 12:43:29 -0800] rev 20235
commands.bookmarks: move hexfn to inside list block This isn't used outside this block, nor is it expected to be.
Tue, 19 Nov 2013 12:42:17 -0800 commands.bookmarks: move cur initialization to inside wlock
Siddharth Agarwal <sid0@fb.com> [Tue, 19 Nov 2013 12:42:17 -0800] rev 20234
commands.bookmarks: move cur initialization to inside wlock This is more correct because we now fetch '.' while nothing else can interfere with it.
Thu, 21 Nov 2013 17:11:04 -0800 commands.bookmarks: pass cur in explicitly to checkconflict
Siddharth Agarwal <sid0@fb.com> [Thu, 21 Nov 2013 17:11:04 -0800] rev 20233
commands.bookmarks: pass cur in explicitly to checkconflict cur will be moved inside the wlock in a future patch, so we need to pass it into checkconflict explicitly.
Tue, 19 Nov 2013 12:33:14 -0800 commands.bookmarks: hold wlock for write operations
Siddharth Agarwal <sid0@fb.com> [Tue, 19 Nov 2013 12:33:14 -0800] rev 20232
commands.bookmarks: hold wlock for write operations Any invocations of bookmarks other than a plain 'hg bookmarks' will likely cause a write to the bookmark store. These should be guarded by the wlock. The repo._bookmarks read should be similarly guarded by the wlock if we're going to be subsequently writing to it.
Tue, 19 Nov 2013 11:47:30 -0800 commands.bookmarks: separate out 'no bookmarks set' status messages
Siddharth Agarwal <sid0@fb.com> [Tue, 19 Nov 2013 11:47:30 -0800] rev 20231
commands.bookmarks: separate out 'no bookmarks set' status messages Upcoming patches will acquire the wlock for write operations, such as make inactive, but not read-only ones, such as list bookmarks. Separate out the status messages so that the code paths can be separated.
Sat, 16 Nov 2013 19:56:53 -0500 tests: test-convert-cvs-synthetic.t requires cvs 1.12
Mads Kiilerich <madski@unity3d.com> [Sat, 16 Nov 2013 19:56:53 -0500] rev 20230
tests: test-convert-cvs-synthetic.t requires cvs 1.12 9589227657bc introduced hghave cvs112 10 months ago. Let's assume it has stabilized so much that we can start using it now.
Mon, 13 Jan 2014 14:33:39 -0600 merge with stable
Matt Mackall <mpm@selenic.com> [Mon, 13 Jan 2014 14:33:39 -0600] rev 20229
merge with stable
Wed, 08 Jan 2014 12:25:00 -0800 i18n-de: rename noun "entfernt" to "Gegenseite" stable
David Soria Parra <davidsp@fb.com> [Wed, 08 Jan 2014 12:25:00 -0800] rev 20228
i18n-de: rename noun "entfernt" to "Gegenseite" The German translation for "remote" as "entfernt" can be misleading in situations where remote is used as a noun. "entfernt" is not a noun and can also mean "removed". To clarify this we rename "remote" to "Gegenseite" when used as a noun.
Fri, 10 Jan 2014 16:26:11 -0600 doc: bump copyright year
Kevin Bullock <kbullock@ringworld.org> [Fri, 10 Jan 2014 16:26:11 -0600] rev 20227
doc: bump copyright year
Fri, 10 Jan 2014 17:29:16 -0600 localrepo: drop unused variable
Matt Mackall <mpm@selenic.com> [Fri, 10 Jan 2014 17:29:16 -0600] rev 20226
localrepo: drop unused variable
Fri, 15 Nov 2013 23:28:43 -0500 discovery: stop using nodemap for membership testing
Pierre-Yves David <pierre-yves.david@ens-lyon.org> [Fri, 15 Nov 2013 23:28:43 -0500] rev 20225
discovery: stop using nodemap for membership testing Nodemap is not aware of filtering so we need to ask the changelog itself if a node is known. This is probably a bit slower but such check does not dominated discovery time. This is necessary if we want to run discovery on filtered repo.
Fri, 15 Nov 2013 23:27:39 -0500 discovery: enforce filtering into revlogbaseddag._internalizeall
Pierre-Yves David <pierre-yves.david@ens-lyon.org> [Fri, 15 Nov 2013 23:27:39 -0500] rev 20224
discovery: enforce filtering into revlogbaseddag._internalizeall One more step toward discovery running on filtered repo.
Fri, 15 Nov 2013 23:27:15 -0500 discovery: make revlogdag work on filtered repo
Pierre-Yves David <pierre-yves.david@ens-lyon.org> [Fri, 15 Nov 2013 23:27:15 -0500] rev 20223
discovery: make revlogdag work on filtered repo The revlogdag class is a core part of discovery. We need its initialisation to exclude revision filtered out.
Sat, 16 Nov 2013 11:53:44 -0500 pull: run findcommon incoming on unfiltered repo
Pierre-Yves David <pierre-yves.david@ens-lyon.org> [Sat, 16 Nov 2013 11:53:44 -0500] rev 20222
pull: run findcommon incoming on unfiltered repo The discovery is not yet ready for filtered repo. Pull was using filtered for its discovery which is wrong. It worked by dumb luck because discovery mainly use funtion that does not respect the filtering. Trying to makes discovery work on filtered repo revealed this bug.
Tue, 05 Nov 2013 18:37:44 +0100 push: more robust check for bundle fast path
Pierre-Yves David <pierre-yves.david@ens-lyon.org> [Tue, 05 Nov 2013 18:37:44 +0100] rev 20221
push: more robust check for bundle fast path When all changesets in the local repo are either being pushed or remotly known, we can take a fast path when bundling changeset because we are certain all local deltas are computed againts base known remotely. So we have a check to detect this situation, when we did a bare push and nothing was excluded. In a coming refactoring, the discovery will run on filtered view and the content of `outgoing.excluded` will just include unserved (secret) changeset not filtered by the repoview used to call push (usually "visible"). So we need to check if there is both no excluded changeset and nothing filtered by the current repoview.
Sat, 16 Nov 2013 15:36:50 -0500 pull: fix post-pull common computation
Pierre-Yves David <pierre-yves.david@ens-lyon.org> [Sat, 16 Nov 2013 15:36:50 -0500] rev 20220
pull: fix post-pull common computation Before that changes, pulled revision that happend to be already known locally (so, not actually added) was not taken into account when computing the new common set between local and remote. It appears that we already know the heads of the pulled set. It is in the `rheads` variable, so we are just using it and everything is works fine. We are dropping the, now useless, computation of `added` set in the process.
(0) -10000 -3000 -1000 -300 -100 -50 -24 +24 +50 +100 +300 +1000 +3000 +10000 +30000 tip