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.
Matt Mackall <mpm@selenic.com> [Thu, 06 Dec 2012 16:42:15 -0600] rev 18037
merge with stable
David Schleimer <dschleimer@fb.com> [Tue, 04 Dec 2012 12:54:18 -0800] rev 18036
merge: support calculating merge actions against non-working contexts
This is not currently used. It is instead a pre-requisite to
performing non-conflicting grafts in memory, which a subsequent patch
will do.
David Schleimer <dschleimer@fb.com> [Tue, 04 Dec 2012 12:54:18 -0800] rev 18035
merge: refactor action calculation into function
This pulls the code used to calculate the changes that need to happen
during merge.update() into a separate function. This is not useful on
its own, but is instead preparatory to performing grafts in memory
when there are no potential conflicts.
Siddharth Agarwal <sid0@fb.com> [Mon, 03 Dec 2012 14:21:45 -0800] rev 18034
dirstate: inline more properties and methods in status
hg perfstatus -u on a working directory with 170,000 files, without this
change:
! wall 1.839561 comb 1.830000 user 1.120000 sys 0.710000 (best of 6)
With this change:
! wall 1.804222 comb 1.790000 user 1.140000 sys 0.650000 (best of 6)
hg perfstatus on the same directory, without this change:
! wall 1.016609 comb 1.020000 user 0.670000 sys 0.350000 (best of 10)
With this change:
! wall 0.985573 comb 0.980000 user 0.650000 sys 0.330000 (best of 10)
Siddharth Agarwal <sid0@fb.com> [Mon, 03 Dec 2012 13:53:53 -0800] rev 18033
perf: add option to perfstatus to get the status of unknown files
When status needs to look at unknown files (e.g. when running hg status), it
needs to use a completely different algorithm than when it doesn't (e.g. when
running hg diff).
Siddharth Agarwal <sid0@fb.com> [Tue, 04 Dec 2012 10:29:18 -0800] rev 18032
dirstate: test normalize is truthy instead of using a no-op lambda
hg perfstatus -u on a working directory with 170,000 files, without this
change:
! wall 1.869404 comb 1.850000 user 1.170000 sys 0.680000 (best of 6)
With this change:
! wall 1.839561 comb 1.830000 user 1.120000 sys 0.710000 (best of 6)
Kevin Bullock <kbullock@ringworld.org> [Tue, 04 Dec 2012 11:19:32 -0600] rev 18031
merge with stable
Matt Mackall <mpm@selenic.com> [Thu, 06 Dec 2012 13:21:27 -0600] rev 18030
hgweb: avoid generator exhaustion with branches
Matt Mackall <mpm@selenic.com> [Wed, 05 Dec 2012 15:38:18 -0600] rev 18029
hgweb: fix iterator reuse in atom feed generation
Julien Cristau <julien.cristau@logilab.fr> [Tue, 04 Dec 2012 14:35:02 +0100] rev 18028
tests: don't hardcode errno==2 for ENOENT
Hurd seems to set ENOENT to 2 + 2**30, unlike everyone else.
Bryan O'Sullivan <bryano@fb.com> [Mon, 03 Dec 2012 13:17:01 -0800] rev 18027
osutil: tab damage, how i hate thee
Bryan O'Sullivan <bryano@fb.com> [Mon, 03 Dec 2012 12:40:24 -0800] rev 18026
osutil: write a C implementation of statfiles for unix
This makes a big difference to performance.
In a clean working directory containing 170,000 files, performance of
"hg --time diff" improves from 2.38 seconds to 1.69.
Wagner Bruna <wbruna@softwareexpress.com.br> [Mon, 03 Dec 2012 19:37:36 -0200] rev 18025
merge with i18n
FUJIWARA Katsunori <foozy@lares.dti.ne.jp> [Fri, 30 Nov 2012 21:39:01 +0900] rev 18024
i18n-ja: synchronized with
f94ead934067
Matt Mackall <mpm@selenic.com> [Mon, 03 Dec 2012 14:03:57 -0600] rev 18023
Added signature for changeset
0c10cf819146
Matt Mackall <mpm@selenic.com> [Mon, 03 Dec 2012 14:03:52 -0600] rev 18022
Added tag 2.4.1 for changeset
0c10cf819146
Bryan O'Sullivan <bryano@fb.com> [Fri, 30 Nov 2012 17:40:11 -0800] rev 18021
osutil: fix tab damage
Bryan O'Sullivan <bryano@fb.com> [Fri, 30 Nov 2012 15:56:09 -0800] rev 18020
Merge with crew
Bryan O'Sullivan <bryano@fb.com> [Fri, 30 Nov 2012 15:55:09 -0800] rev 18019
osutil: factor out creation and init of listdir_stat
Bryan O'Sullivan <bryano@fb.com> [Fri, 30 Nov 2012 15:55:08 -0800] rev 18018
dirstate: avoid use of zip on big lists
In a clean working directory containing 170,000 tracked files, this
improves performance of "hg --time diff" from 1.69 seconds to 1.43.
This idea is due to Siddharth Agarwal.
Bryan O'Sullivan <bryano@fb.com> [Fri, 30 Nov 2012 15:55:07 -0800] rev 18017
dirstate: move file type filtering to its source
This prepares us to move to a much faster statfiles implementation on Unix.
Pierre-Yves David <pierre-yves.david@ens-lyon.org> [Fri, 30 Nov 2012 22:34:21 +0100] rev 18016
clfilter: rename `unfilteredmeth` to `unfilteredmethod`
As originally intended.
Pierre-Yves David <pierre-yves.david@logilab.fr> [Fri, 30 Nov 2012 21:47:04 +0100] rev 18015
clfilter: fix a false positive in the test-obsolete.t
We push between two repo which once filtered looks unrelated. Weakness in the
current implementation allows this push to be done without -f. But later
improvement with filtering will make this push fails for unrelatedness. However
we want this push to fail for including bumped changeset. So we had a smaller
push --force to make them related.
Pierre-Yves David <pierre-yves.david@logilab.fr> [Mon, 08 Oct 2012 19:34:04 +0200] rev 18014
clfilter: ensure that filecache on localrepo is unfiltered
All filecache usage on repo is for logic that should be unfiltered. The
caches should be common to all filtered instances, and computation must
be done unfiltered. A dedicated storecache subclass is created for
this purpose.
Pierre-Yves David <pierre-yves.david@logilab.fr> [Mon, 08 Oct 2012 20:02:20 +0200] rev 18013
clfilter: add a propertycache that must be unfiltered
Some of the localrepo property caches must be computed unfiltered and
stored globally. Some others must see the filtered version and store data
relative to the current filtering.
This changeset introduces two classes `unfilteredpropertycache`
and `filteredpropertycache` for this purpose. A new function
`hasunfilteredcache` is introduced for unambiguous checking for cached
values on unfiltered repos.
A few tweaks are made to the property cache class to allow overriding
the way the computed value is stored on the object.
Some logic relative to _tagcaches is cleaned up in the process.