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
Mads Kiilerich <madski@unity3d.com> [Thu, 13 Dec 2012 19:19:06 +0100] rev 18066
largefiles: align rm warnings with warnings used in core
Mads Kiilerich <madski@unity3d.com> [Thu, 13 Dec 2012 21:34:55 +0100] rev 18065
merge with 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.
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().
Siddharth Agarwal <sid0@fb.com> [Thu, 06 Dec 2012 11:21:11 -0800] rev 18062
perf: add a command to measure revset performance
Bryan O'Sullivan <bos@serpentine.com> [Wed, 12 Dec 2012 15:17:18 -0800] rev 18061
run-tests: fix whitespace nonsense
Bryan O'Sullivan <bos@serpentine.com> [Wed, 12 Dec 2012 15:12:28 -0800] rev 18060
merge with mpm
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.
Siddharth Agarwal <sid0@fb.com> [Tue, 11 Dec 2012 15:38:42 -0800] rev 18058
run-tests: fix exename 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.
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
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 =)
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
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.
Mads Kiilerich <madski@unity3d.com> [Sun, 09 Dec 2012 23:33:16 +0100] rev 18052
contrib: state explicitly how hgtest.vim can be installed
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
Bryan O'Sullivan <bryano@fb.com> [Mon, 10 Dec 2012 12:14:55 -0800] rev 18050
run-tests: use correct python safely under --jobs
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
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
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
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.
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).
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
Kevin Bullock <kbullock@ringworld.org> [Fri, 07 Dec 2012 11:30:38 -0600] rev 18043
bookmarks: spelling correction in docstring
Kevin Bullock <kbullock@ringworld.org> [Thu, 06 Dec 2012 22:07:44 -0600] rev 18042
merge: fix mistake in moved _checkcollision call from
5881d5b7552f
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
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.
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.
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.