Sun, 09 Dec 2012 00:25:21 +0100 mq: don't fail when removing a patch without patch file from series file
Mads Kiilerich <mads@kiilerich.com> [Sun, 09 Dec 2012 00:25:21 +0100] rev 18067
mq: don't fail when removing a patch without patch file from series file
Thu, 13 Dec 2012 19:19:06 +0100 largefiles: align rm warnings with warnings used in core
Mads Kiilerich <madski@unity3d.com> [Thu, 13 Dec 2012 19:19:06 +0100] rev 18066
largefiles: align rm warnings with warnings used in core
Thu, 13 Dec 2012 21:34:55 +0100 merge with stable
Mads Kiilerich <madski@unity3d.com> [Thu, 13 Dec 2012 21:34:55 +0100] rev 18065
merge with stable
Mon, 10 Dec 2012 14:58:42 +0100 largefiles: commit directories that only contain largefiles (issue3548) stable
Levi Bard <levi@unity3d.com> [Mon, 10 Dec 2012 14:58:42 +0100] rev 18064
largefiles: commit directories that only contain largefiles (issue3548) If we pass a directory to commit whose only commitable files are largefiles, the core commit code aborts before finding the largefiles. So we do the following: For directories that only have largefiles as matches, we explicitly add the largefiles to the matchlist and remove the directory. In other cases, we leave the match list unmodified.
Fri, 07 Dec 2012 10:37:43 -0800 revset.children: ignore rev numbers that are too low
Siddharth Agarwal <sid0@fb.com> [Fri, 07 Dec 2012 10:37:43 -0800] rev 18063
revset.children: ignore rev numbers that are too low This replaces unnecessary parentrevs() calls with calculating min(parentset). Even though the min operation is O(size of parentset), since parentrevs is relatively expensive, this tradeoff almost always works in our favour. In a repository with over 400,000 changesets, hg perfrevset "children(X)" takes: Set X Before After -1 0.51s 0.06s -1000: 0.55s 0.08s -10000: 0.56s 0.10s -100000: 0.60s 0.25s -100000:-99000 0.55s 0.19s 0:100000 0.60s 0.61s all() 0.72s 0.74s The relative performance is similar for Mercurial's own repository -- several times faster in most cases, slightly slower for revisions close to 0 and all().
Thu, 06 Dec 2012 11:21:11 -0800 perf: add a command to measure revset performance
Siddharth Agarwal <sid0@fb.com> [Thu, 06 Dec 2012 11:21:11 -0800] rev 18062
perf: add a command to measure revset performance
Wed, 12 Dec 2012 15:17:18 -0800 run-tests: fix whitespace nonsense
Bryan O'Sullivan <bos@serpentine.com> [Wed, 12 Dec 2012 15:17:18 -0800] rev 18061
run-tests: fix whitespace nonsense
Wed, 12 Dec 2012 15:12:28 -0800 merge with mpm
Bryan O'Sullivan <bos@serpentine.com> [Wed, 12 Dec 2012 15:12:28 -0800] rev 18060
merge with mpm
Wed, 12 Dec 2012 14:52:58 -0800 run-tests: on windows, put correct python at front of PATH
Bryan O'Sullivan <bryano@fb.com> [Wed, 12 Dec 2012 14:52:58 -0800] rev 18059
run-tests: on windows, put correct python at front of PATH The older approach of trying to copy the python executable into the test directory was doomed to fail. There remains one weakness with this approach: if you've run "make local", tests may pick up the wrong extension DLLs from inside the source tree. I don't know why this happens. A reasonable workaround for now is to test either using --local or with a working directory that does not contain built DLLs.
Tue, 11 Dec 2012 15:38:42 -0800 run-tests: fix exename on Windows
Siddharth Agarwal <sid0@fb.com> [Tue, 11 Dec 2012 15:38:42 -0800] rev 18058
run-tests: fix exename on Windows
Tue, 11 Dec 2012 15:13:23 -0800 run-tests: support running tests in parallel on windows
Bryan O'Sullivan <bryano@fb.com> [Tue, 11 Dec 2012 15:13:23 -0800] rev 18057
run-tests: support running tests in parallel on windows Previously, we used os.spawnvp, which doesn't exist on Windows, and isn't needed anyway (the command line begins with an absolute path). We also need a slightly more convoluted way to wait for processes without specifying an order on Windows, as it lacks os.wait.
Tue, 11 Dec 2012 13:44:00 -0800 makefile: allow local builds to work on windows/mingw32
Bryan O'Sullivan <bryano@fb.com> [Tue, 11 Dec 2012 13:44:00 -0800] rev 18056
makefile: allow local builds to work on windows/mingw32
Sun, 09 Dec 2012 23:33:16 +0100 check-code: make 'missing whitespace in assignment' more aggressive
Mads Kiilerich <madski@unity3d.com> [Sun, 09 Dec 2012 23:33:16 +0100] rev 18055
check-code: make 'missing whitespace in assignment' more aggressive New warnings: > a.b=ab missing whitespace in assignment (the pattern did not accept '.' on the left hand side) > a=a missing whitespace in assignment (the right hand side pattern never matched a single character) > a=a + 7 missing whitespace in assignment (the pattern only matched one character after the identifier following =)
Sun, 09 Dec 2012 23:33:16 +0100 check-code: there must also be whitespace between ')' and operator
Mads Kiilerich <madski@unity3d.com> [Sun, 09 Dec 2012 23:33:16 +0100] rev 18054
check-code: there must also be whitespace between ')' and operator The check pattern only checked for whitespace between keyword and operator. Now it also warns: > x = f(),7 missing whitespace after , > x = f()+7 missing whitespace in expression
Sun, 09 Dec 2012 23:33:16 +0100 rm: drop misleading 'use -f' hint for the rm --after 'not removing' warning
Mads Kiilerich <madski@unity3d.com> [Sun, 09 Dec 2012 23:33:16 +0100] rev 18053
rm: drop misleading 'use -f' hint for the rm --after 'not removing' warning A warning mentioning 'forgetting' or 'recording delete' would be more correct than 'not removing' but also more confusing.
Sun, 09 Dec 2012 23:33:16 +0100 contrib: state explicitly how hgtest.vim can be installed
Mads Kiilerich <madski@unity3d.com> [Sun, 09 Dec 2012 23:33:16 +0100] rev 18052
contrib: state explicitly how hgtest.vim can be installed
Sun, 09 Dec 2012 23:33:16 +0100 tests: kill daemons early, making breaking at "Accept" prompt safe
Mads Kiilerich <madski@unity3d.com> [Sun, 09 Dec 2012 23:33:16 +0100] rev 18051
tests: kill daemons early, making breaking at "Accept" prompt safe
Mon, 10 Dec 2012 12:14:55 -0800 run-tests: use correct python safely under --jobs
Bryan O'Sullivan <bryano@fb.com> [Mon, 10 Dec 2012 12:14:55 -0800] rev 18050
run-tests: use correct python safely under --jobs
Mon, 10 Dec 2012 12:09:02 -0800 run-tests: check for the correct python when starting
Bryan O'Sullivan <bryano@fb.com> [Mon, 10 Dec 2012 12:09:02 -0800] rev 18049
run-tests: check for the correct python when starting
Mon, 10 Dec 2012 12:07:42 -0800 run-tests: use correct python when run with --local
Bryan O'Sullivan <bryano@fb.com> [Mon, 10 Dec 2012 12:07:42 -0800] rev 18048
run-tests: use correct python when run with --local
Mon, 10 Dec 2012 11:18:03 -0800 synthrepo: do not crash if a list is empty
Bryan O'Sullivan <bryano@fb.com> [Mon, 10 Dec 2012 11:18:03 -0800] rev 18047
synthrepo: do not crash if a list is empty
Tue, 27 Nov 2012 22:24:02 +0100 hgwebdir: do not show RSS and Atom links for plain directories
Angel Ezquerra <angel.ezquerra@gmail.com> [Tue, 27 Nov 2012 22:24:02 +0100] rev 18046
hgwebdir: do not show RSS and Atom links for plain directories Up until now the templates that show RSS and Atom feeds on the "repository lists" (i.e. gitweb and monoblue) showed them for all entries, including regular folders. Clicking on those "folder RSS" links would result in an error page being shown. This patch hides those links for regular folders.
Tue, 04 Dec 2012 00:37:50 +0100 hgweb: add branches RSS and Atom feeds
Angel Ezquerra <angel.ezquerra@gmail.com> [Tue, 04 Dec 2012 00:37:50 +0100] rev 18045
hgweb: add branches RSS and Atom feeds There were no RSS nor Atom feeds for the branches page. Different hgweb templates linked to different feeds on their branches page (some linked to the tags feed, some to the log feed and some to the unexisting branches feed).
Fri, 07 Dec 2012 12:03:37 -0600 push: reunite comment with the line of code it describes
Kevin Bullock <kbullock@ringworld.org> [Fri, 07 Dec 2012 12:03:37 -0600] rev 18044
push: reunite comment with the line of code it describes
Fri, 07 Dec 2012 11:30:38 -0600 bookmarks: spelling correction in docstring
Kevin Bullock <kbullock@ringworld.org> [Fri, 07 Dec 2012 11:30:38 -0600] rev 18043
bookmarks: spelling correction in docstring
Thu, 06 Dec 2012 22:07:44 -0600 merge: fix mistake in moved _checkcollision call from 5881d5b7552f
Kevin Bullock <kbullock@ringworld.org> [Thu, 06 Dec 2012 22:07:44 -0600] rev 18042
merge: fix mistake in moved _checkcollision call from 5881d5b7552f
Thu, 06 Dec 2012 16:56:44 -0600 windows: correctly pass a mode to S_IFMT in statfiles
Matt Mackall <mpm@selenic.com> [Thu, 06 Dec 2012 16:56:44 -0600] rev 18041
windows: correctly pass a mode to S_IFMT in statfiles
Wed, 05 Dec 2012 14:33:15 -0800 strip: make query to get new bookmark target cheaper
Siddharth Agarwal <sid0@fb.com> [Wed, 05 Dec 2012 14:33:15 -0800] rev 18040
strip: make query to get new bookmark target cheaper The current query to get the new bookmark target for stripped revisions involves multiple walks up the DAG, and is really expensive, taking over 2.5 seconds on a repository with over 400,000 changesets even if just one changeset is being stripped. A slightly simplified version of the current query is max(heads(::<tostrip> - <tostrip>)) We make two observations here. 1. For any set s, max(heads(s)) == max(s). That is because revision numbers define a topological order, so that the element with the highest revision number in s will not have any children in s. 2. For any set s, max(::s - s) == max(parents(s) - s). In other words, the ancestor of s with the highest revision number not in s is a parent of one of the revs in s. Why? Because if it were an ancestor but not a parent of s, it would have a descendant that would be a parent of s. This descendant would have a higher revision number, leading to a contradiction. Combining these two observations, we rewrite the revset query as max(parents(<tostrip>) - <tostrip>) The time complexity is now linear in the number of changesets being stripped. For the above repository, the query now takes 0.1 seconds when one changeset is stripped. This speeds up operations that use repair.strip, like the rebase and strip commands.
Tue, 04 Dec 2012 12:54:18 -0800 graft: explicit current node tracking
David Schleimer <dschleimer@fb.com> [Tue, 04 Dec 2012 12:54:18 -0800] rev 18039
graft: explicit current node tracking This changes graft to explicitly track the progression of commits it makes, and updates it's idea of the current node based on it's last commit, rather than from the working copy parent. This should have no effect on the value of current since we were reading the working copy parent immediately after commiting to it. The motivation for this change is that a subsequent patch will break the current node and working copy relationship. Splitting this out into a separate patch will make that one more readible.
Tue, 04 Dec 2012 12:54:18 -0800 graft: move commit info building
David Schleimer <dschleimer@fb.com> [Tue, 04 Dec 2012 12:54:18 -0800] rev 18038
graft: move commit info building This moves the logic for generating the commit metadata ahead of the merge operation. The only purposae of this patch is to make subsequent patches easier to read, and there should be no behavior changes.
(0) -10000 -3000 -1000 -300 -100 -50 -30 +30 +50 +100 +300 +1000 +3000 +10000 +30000 tip