This can happen when a file with flags is removed or deleted in the working
directory and also not present in m2. The obvious solution is to add a
__delitem__ override to manifestdict that removes the file from flags if
necessary, but that has a significant performance cost in some cases, e.g.
hg status --rev rev1 --rev rev2 <file>.
This is not only a bit faster, but also aligns with callers' expectations
better since we can legitimately have manifestdict's _flags set to '' instead
of unset.
hg perfmergecalculate -r .
before: ! wall 0.139582 comb 0.140000 user 0.140000 sys 0.000000 (best of 59)
after: ! wall 0.126154 comb 0.120000 user 0.120000 sys 0.000000 (best of 74)
hg perfmergecalculate -r .^
before: ! wall 0.236333 comb 0.240000 user 0.240000 sys 0.000000 (best of 36)
after: ! wall 0.212265 comb 0.210000 user 0.210000 sys 0.000000 (best of 45)
Before this patch, the certificate of the SMTP server for STARTTLS or
SMTPS isn't verified.
This may cause man-in-the-middle security problem (stealing
authentication information), even though SMTP channel itself is
encrypted by SSL.
When "[smtp] tls" is configured as "smtps" or "starttls", this patch:
- uses classes introduced by preceding patches instead of "SMTP" or
"SMTP_SSL" of smtplib, and
- verifies the certificate of the SMTP server, if "[smtp]
verifycert" is configured as other than False
"[smtp] verifycert" can be configured in 3 levels:
- "strict":
This verifies peer certificate, and aborts if:
- peer certification is not valid, or
- no configuration in "[hostfingerprints]" and "[web] cacerts"
This is default value of "[smtp] verifycert" for security.
- "loose":
This verifies peer certificate, and aborts if peer certification is
not valid.
This just shows warning message ("certificate not verified"), if
there is no configuration in "[hostfingerprints]" and "[web]
cacerts".
This is as same as verification for HTTPS connection.
- False(no verification):
Peer certificate is not verified.
This is as same as the behavior before this patch series.
"hg email --insecure" uses "loose" level, and ignores "[web] cacerts"
as same as push/pull/etc... with --insecure.
Ignoring "[web] cacerts" configuration for "hg email --insecure" is
already done in "dispatch._dispatch()" by looking "insecure" up in the
table of command options.
Before this patch, "sslutil.validator" may returns successfully, even
if peer certificate is not verified because there is no information in
"[hostfingerprints]" and "[web] cacerts".
To prevent from sending authentication credential to untrustable SMTP
server, validation should be aborted if peer certificate is not
verified.
This patch introduces "strict" optional argument, and
"sslutil.validator" will abort if it is True and peer certificate is
not verified.
Original "smtplib.SMTP_SSL" has no route to pass "ca_certs" and
"cert_reqs" arguments to underlying SSL socket creation. This causes
that "getpeercert()" on SSL socket returns empty dict, so the peer
certificate for SMTPS can't be verified.
This patch introduces the "SMTPS" class derived from "smtplib.SMTP" to
pass "ca_certs" and "cert_reqs" arguments to underlying SSL socket
creation.
"SMTPS" class is derived directly from "smtplib.SMTP", because amount
of "smtplib.SMTP_SSL" definition derived from "smtplib.SMTP" is as
same as one needed to override it.
This patch defines "SMTPS" class, only when "smtplib.SMTP" class has
"_get_socket()" method, because this makes using SSL socket instead of
normal socket easy.
"smtplib.SMTP" class of Python 2.5.x or earlier doesn't have this
method. Omitting SMTPS support for them is reasonable, because
"smtplib.SMTP_SSL" is already unavailable for them before this patch.
Almost all code of "SMTPS" class is imported from "smtplib.SMTP_SSL"
of Python 2.7.3, but it differs from original code in point below:
- "ssl.wrap_socket()" is replaced by "sslutil.ssl_wrap_socket()" for
compatibility between Python versions
Original "smtplib.SMTP" has no route to pass "ca_certs" and
"cert_reqs" arguments to underlying SSL socket creation. This causes
that "getpeercert()" on SSL socket returns empty dict, so the peer
certificate for STARTTLS can't be verified.
This patch introduces the "STARTTLS" class derived from "smtplib.SMTP"
to pass "ca_certs" and "cert_reqs" arguments to underlying SSL socket
creation.
Almost all code of "starttls()" in this class is imported from
"smtplib.SMTP" of Python 2.7.3, but it differs from original code in
points below:
- "self.ehlo_or_helo_if_needed()" invocation is omitted, because:
- "ehlo_or_helo_if_needed()" is available with Python 2.6 or later, and
- "ehlo()" is explicitly invoked in "mercurial.mail._smtp()"
- "if not _have_ssl:" check is omitted, because:
- "_have_ssl" is available with Python 2.6 or later, and
- same checking is done in "mercurial.sslutil.ssl_wrap_socket()"
- "ssl.wrap_socket()" is replaced by "sslutil.ssl_wrap_socket()" for
compatibility between Python versions
- use "sock.recv()" also as "sock.read()", if "sock" doesn't have
"read()" method
with Python 2.5.x or earlier, "sslutil.ssl_wrap_socket()" returns
"httplib.FakeSocket"-ed object, and it doesn't have "read()"
method, which is invoked via "smtplib.SSLFakeFile".
When the revisions to graft are numerically close to the destination, this
avoids two walks up the DAG, which for a repository with over 470,000
changesets translates to around 2.2 seconds.
When the revisions to graft are numerically close to the destination, this
avoids one walk up the DAG, which for a repository with over 470,000
changesets translates to around 1.1 seconds.
This is a performance win for a number of reasons:
- We don't iterate over contexts, which avoids a completely unnecessary sorted
call + the O(number of files) abstraction cost of doing that.
- We don't check membership in a context, which avoids another
O(number of files) abstraction cost.
- We iterate over the manifests in C instead of Python.
For a large repo with 170,000 files, this improves perfpathcopies from 0.34
seconds to 0.07. Anything that uses pathcopies, such as rebase or diff --git
between two revisions, benefits.
This makes a big difference to performance in some cases.
hg --time locate 'set:symlink()'
mozilla-central (70,000 files):
before: 2.92 sec
after: 2.47
another repo (170,000 files):
before: 7.87 sec
after: 6.86
Now that we no longer sort all the walk results, using iteritems becomes
possible.
This is a relatively minor speedup: on a large repository with 170,000 files,
perfaddremove goes from 2.13 seconds to 2.10.
The only place where the order matters is in printing out added or removed
files. We already sort that set.
On a large repository with 170,000 files, this speeds up perfaddremove from
2.34 seconds to 2.13.
This will let us stop sorting all the results in an upcoming patch.
This also permits future refactorings where the same code consumes
dirstate.walk results but doesn't print anything out.
An argument could be made that printing out results as we go along is more
responsive UI-wise. However, at this point iterating through walk results is
actually faster than sorting them, so once we stop sorting all the results the
argument ceases to be valid.
dirstate.walk only does lstats and never returns stat objects for directories.
On a large repository with 170,000 files, this speeds perfaddremove up from
2.40 seconds to 2.34.
Consider the following repo:
0 -- 1 (renames a to b)
\
- 2
If we're rebasing 2 onto 1, then duplicatecopies is called with arguments (2,
1). copies.pathcopies goes backwards from 1 to 0 and returns the pair dst = a,
src = b. Of course, since we're working on top of 2, at this point a doesn't
exist in the dirstate.
Extra entries in the copymap are currently harmless because the copymap is
only queried for items in the dirstate map. However, if the dirstate.copy
method becomes one of the sources used to determine which files have changed,
this will prove problematic.
Note that we can't avoid going backwards in general -- consider this repo:
0 -- 1 (renames a to b)
\
- 2 (renames a to c)
Rebasing 2 onto 1 should produce a rename from b to c.
Consider a bookmark B that exists both locally and remotely. If B is updated
remotely, and then a pull is performed where the pull set contains the new
location of B, the bookmark is updated locally. However, if remote B is
updated in the middle of a pull to a location not in the pull set, the
bookmark won't be updated locally at all.
To fix this, list bookmarks before pulling in changesets, not after. This
still leaves a race open if B gets moved in between listing bookmarks and
pulling in changesets, but the race window is much smaller. Fixing the race
properly would require a bundle format upgrade.
test-hook.t's output changes because we no longer do two listkeys calls during
pull, just one.
test-pull-http.t's output changes because we now search for bookmarks before
searching for changes.
This reduces the likelihood of a traceback when trying to email a
patch that happens to have 'diff --git' at the beginning of a line
in the description, as this patch did:
http://markmail.org/message/wxpgowxd7ucxygwe
Recreate the repo with the global configuration in repo.baseui. The repo
configuration is reread anyway. And now deleted repo configuration is reset to
the default value.
If exception is error.LookupError and running in i18n environment,
below condition is always true.
Because msg is translated and dosen't contain 'manifest'.
if util.safehasattr(err, 'name') and 'manifest' not in msg:
This patch creates a new exception class and uses it instead of
string match.
When the strip command is run, it calls repo.destroyed, which in turn checks if
we read _phasecache, and if we did calls filterunknown on it and flushes the
changes immediately. But in some cases, nothing causes _phasecache to be read,
so we miss out on this and the file remains the same on-disk.
Then a call to invalidate comes, which should refresh _phasecache if it
changed, but it didn't, so it keeps using the old one with the stripped
revision which causes an IndexError.
Test written by Yuya Nishihara.
Before this patch, "hg bundle --branch foo other" fails to create
bundle file, if specified "foo" branch is created newly on the local
repository.
"hg bundle" uses "hg.addbranchrevs(repo, other, ...)" to look branch
names up, even though other outgoing-like implementation uses
"hg.addbranchrevs(repo, repo, ...)". In the former invocation, "other"
repository recognizes such branches as unknown, so execution is
aborted.
This patch uses "hg.addbranchrevs(repo, repo, ..)" in "hg bundle" to
bundle revisions on such branches correctly.
If there is no outgoiing changesets but we have filtered revision in outgoing.excluded
We run into a filtering related crash. The excluded revision should not be there
in the first place but discovery need cleanup in default, not stable.
In its current state discovery may return (remotely) filtered elements
in "common". This has usually no impact as "missing" is kept clear of
filtered elements. However when the "remote" repo is a local repo (disk
accessible, and directly created in memory) the incoming code takes a
shortcut and directly uses the "remote" repo to generate the incoming
output. When some common elements are filtered this led to a crash. We
now ensure we use an unfiltered repository to generate the incoming
output. This does not change the behavior as missing is clear of
filtered revision.
Now that we have proper low level filtering, incoming code needs a
deeper cleanup but it is already planned.
Since the 'summary' view used by e.g. gitweb and monoblue shows both a
changelog and a bookmarks list, the same changes are needed here as were
made to the 'changelog' and 'bookmarks' web commands (2be8fa4eef83 and
70f6745775fa, respectively).
79f69be29aed introduced a crash when cloning a url without path - where
util.url().path would be None.
This None will now be handled as ''. clone will thus abort with 'repository /
not found' as before.
The internal WSGI emulation in wsgicgi.py was not fully WSGI compliant and
assumed that all responses sent a body. With a9df76d7ca1f that caused a real
bug when using hgweb.cgi.
wsgicgi.py will now make sure headers always are sent, using the pattern from
PEP 333 and similar to how it is done in 38e07483cc16.
Without this, repository paths or names containing e.g. & characters or html
tags yielded strange results, possibly allowing cross-site scripting attacks.
More accurately reflects what it will be used for, and is also shorter.
This template is used to change which rev the current rev is diff'd
against. For example, if you're at '/rev/P1:REV', this would link to a
path like '/rev/P2:REV'.
Example usage in a template:
{parent%difffrom}
The user interface introduced in 3ff83729b63f is not considered ready
for prime time yet. The internal code stays in place for custom template
usage. The feature is ultimately wanted and will be re-enabled soon. The
current issue is only related to the visual of the current interface.
The web.prefix setting was being ignored when creating the index URL
breadcrumbs.
We only need to fix hgwebdir and not hgweb because hgweb gets the complete URL
request, including the prefix, while hgwebdir gets a "subdir" which does not
include the prefix.
This fix is slightly different of what was suggested on the bug tracker. In
there it was suggested to hide the prefix itself from the breadcrumb. I think
that would be a better solution, but it would require changing all the index
templates and passing the prefix to the template engine, which may be too big
a change for stable during the freeze. For now this fixes the problem, and the
fix could be improved during the next cycle.
This options add a new `web.view` to control filter level of hgweb.
This option have two purposes:
1) Allow fall back to unfiltered version in case a yet undetected by critical
bug is found in filtering after 2.5 release
2) People use hgweb as a local repoviewer. When they have secret changesets,
they wants to use "visible" filter not "served"
(modified by mpm, documentation deferred)
I noticed that access to filtered revision returned HTTP 500 code (internal
server error). Investigation shown that it was the case for unknown revision
too. That wrong and we now properly return a 404 for revision not found.
Publishing server may contains draft changeset when they are created locally. As
publishing is the default, it is actually fairly common. Because of this
"inconsistency" phases synchronization may be done even to publishing server.
This may cause severe issues for subrepo. It is possible to reference read-only
repository as subrepo. Push in a super repo recursively push subrepo. Those
pushes to potential read only repo are not optional, they are "suffered" not
"choosed". This does not break because as the repo is untouched the push is
supposed to be empty. If the reference repo locally contains draft changesets, a
courtesy push is triggered to turn them public. As the repo is read only, the
push fails (after possible prompt asking for credential). Failure of the
sub-push aborts the whole subrepo push. This force the user to define a custom
default-push for such subrepo.
This changeset introduce a prevention of this error client side by skipping the
courtesy phase synchronisation in problematic situation. The phases
synchronisation is skipped when four conditions are gathered:
- this is a subrepo push, (normal push to read-only repo)
- and remote support phase
- and remote is publishing
- and no changesets was pushed (if we pushed changesets, repo is not read only)
The internal config option used in this version is not definitive. It is here to
demonstrate a working fix to the issue.
In the future we probably wants to track subrepo changes and avoid pushing to
untouched one. That will prevent any attempt to push to read-only or unreachable
subrepo.
Another fix to prevent courtesy push from older clients to push to newer server
is also still needed.
Locating the share source when no default path is available is now handled in
subrepo._abssource(), so unconditionally setting a default path (and the
associated problems) can be avoided.
The test change reflects the fact that a default path is no longer set on the
resulting share.
This is an alternative fix for issue3518, enabling sharing of repositories with
subrepos, without unconditionally setting the default path in the resulting
repo's hgrc file. Better test coverage is added here, but won't prove this code
is working until f48752441ca0 is backed out.
The problem with the original fix is, if a default path is not available to be
copied over from the share source, the default path on the resulting repo is set
to the source location. Since that's where the actual repository is stored, the
path is essentially self-referential, so push, pull, incoming and outgoing
effectively operate on itself. While incoming and outgoing make it look like
nothing was changed, push currently hangs (see issue3657). In this case where
there is not a real default path, these operations should abort with
"default(-push) not found", like the source repo would. Note this problem with
the original fix affected repos without subrepos too.
Since 2852b9b207e9, raw_length can be reduced on strip, but corresponding cache
entries still have refcount. They are not dereferenced by _index_clearcache(),
and never freed.
To reproduce the problem, run "hg pull" and "hg strip null" several times
in the same process.
This is similar to what is done in encoding.lower, introduced in e7a5733d533f.
This has been seen making 'hg up' and 'hg st' in a 50000+ files repo 13%
faster.
This might make Mercurial slightly slower for users who mainly use non-ASCII
filenames. That is a reasonable trade-off.
When you have obsolescence marker that apply to a pulled changesets, the added
changeset is immediately filtered. Then the list of added changeset needs to be
build against and unfiltered repo.
Don't expose unserved changesets to remote repos. Thanks to Sean Farley
<sean.michael.farley@gmail.com> for tracking down the issue and
Pierre-Yves David <pierre-yves.david@ens-lyon.org> for the fix.
We noa pass an unfiltered repo in the same way `localrepo.push` does. This does
not alter outgoing behavior and prevents possible crash with computing
common/missing.
The `findcommonincoming` code could be simplified to make this unnecessary, but
this is too much change for the freeze.
If the active bookmark doesn't point at a parent of the working dir
(e.g. a pull moved it out from under us), we nonetheless show it as
active. This follows on 13ea5e437ff8 in removing the dichotomy (at least
in the UI) between "current" and "active" bookmarks.
Before this patch, sub expression may return unexpected result, if it
is joined with another expression by "or":
- "^"/parentspec():
"R or R^1" is not equal to "R^1 or R". the former returns only "R".
- "~"/ancestorspec():
"R or R~1" is not equal to "R~1 or R". the former returns only "R".
- ":"/rangeset():
"10 or (10 or 15):" is not equal to "(10 or 15): or 10". the
former returns only 10 and 15 or grater (11 to 14 are not
included).
In "or"-ed expression "A or B", the "subset" passed to evaluation of
"B" doesn't contain revisions gotten from evaluation of "A", for
efficiency.
In the other hand, "stringset()" fails to look corresponding revision
for specified string/symbol up, if "subset" doesn't contain that
revision.
So, predicates looking revisions up indirectly should evaluate sub
expressions of themselves not with passed "subset" but with "entire
revisions in the repository", to prevent "stringset()" from unexpected
failing to look symbols in them up.
But predicates in above example don't so. For example, in the case of
"R or R^1":
1. "R^1" is evaluated with "subset" containing revisions other than
"R", because "R" is already gotten by the former of "or"-ed
expressions
2. "parentspec()" evaluates "R" of "R^1" with such "subset"
3. "stringset()" fails to look "R" up, because "R" is not contained
in "subset"
4. so, evaluation of "R^1" returns no revision
This patch evaluates sub expressions for predicates above with "entire
revisions in the repository".
If the current bookmark (the one listed in .hg/bookmarks.current)
doesn't point to a parent of the working directory, e.g. if it was moved
by a pull, use that as the update target instead of the tipmost
descendent.
A small predicate is (finally) added to the bookmarks module to check
whether the current bookmark is also active.
For the special case, ":null" we remove the implied revision 0 since that
wouldn't make any sense here. A test case is added to make sure only nullrev is
shown.
We can not use `len(repo,changelog)`, it may be a filtered revision. We now use
`repo,changelog.tip()` to fetch this information.
The `tip` command is also fixed and tested
Thanks goes to Idan Kamara for the initial report.
With changelog filtering, we can not use xrange anymore. We have to use the
changelog to do the iteration. This way, the changelog excludes filtered
revision and we can safely use what we iterate over.
Without this changes, bisect crash with a traceback if there is filtered
revision in the repo. Tests have been updated.
We have a very handy assert at the ends of `branchmap.updatecache` that check
the resulting branchmap is actually valid.
I know we do not like assert in mercurial but this one is very handy for
debugging. There is really not reason for `branchmap.updatecache` to have this
kind of issue but this happened and handful of time during the development of
this or introduction of other related feature. I advice to keep it around until
we are a bit more confident with the new code.
Creating a new changelog object for each access is costly and prevents efficient
caching changelog side. This introduced a x5 performance regression in log
because chunk read from disk were never reused. We were jumping from about 100
disk read to about 20 000.
This changeset introduce a simple cache mechanism that help the last changelog
object created by a repoview. The changelog is reused until the changelog or the
filtering changes.
The cache invalidation is much more complicated than it should be. But MQ test
show a strange cache desync. I was unable to track down the source of this
desync in descent time so I'm not sure if the issue is in MQ or core. However
given the proximity to the 2.5 freeze, I'm choosing the inelegant but safe route
that makes the cache mechanism safer.
If for some reason the phase roots contains nullid, the set of filtered revs
will contains -1. That confuse Mercurial a lot. In particular this corrupt the
branchcache.
Standard code path does not result in nullid phase root. It can only result from
altered `.hg/store/phaseroots` or buggy extension. However better safe than
sorry.
A file's atime might change even if the file itself doesn't change. This might
cause us to invalidate caches more often than necessary.
Before this change, hg add often resulted in the dirstate being parsed twice
on systems that track atime. After this change, it is only parsed once. For a
repository with over 180,000 files, this speeds up hg add from 1.2 seconds to
1.0.
A repo should not get the configuration from an other repo, so create it with
the global configuration in repo.baseui.
This is done too when recreating a repo. The repo configuration is reread
anyway. And now deleted repo configuration does not persist.
This patch improves manifestmerge performance significantly.
In a repository with 170,000 files, the following results were observed on a
clean working directory. Revision '.' adds one file.
hg perfmergecalculate -r .
- before: 0.41 seconds
- after: 0.13 seconds
hg perfmergecalculate -r .^
- before: 0.53 seconds
- after: 0.24 seconds
Comparing against '.' is much faster than comparing against '.^' because with
'.', the wctx and p2 manifest strings have the same identity, so comparisons
are simply pointer equality. With '.^', the strings have different identities
so we need to perform memcmps.
Any operation that uses manifestmerge benefits.
- hg update . goes from 2.04 seconds to 1.75
- hg update .^ goes from 2.52 seconds to 2.25
- hg rebase -r . -d .~6 (involves 4 merges) goes from 11.8 seconds to 10.8
Given two dicts, diff returns a dict containing all the keys that are present
in one dict but not the other, or whose values are different between the
dicts. The values are pairs of the values from the dicts, with missing values
being represented as an optional argument, defaulting to None.
Given two dicts, join performs what is known as an outer join in relational
database land: it returns a dict containing all the keys across both dicts.
The values are pairs as above, except they aren't compared to see if they're
the same.
An upcoming patch will speed dirstate.walk up by not querying the results dict
when it is empty. This ensures it is in some common cases.
This should be safe because subrepos and .hg aren't part of the dirstate.
Suppose we want to perform a single-level completion (i.e. without
--full) of "fi" in a repo containing "fee", "fie/dead", "fie/live",
and "foe".
If we give back "fie/" as the only answer, the shell will consider
the completion to be unambiguous, and will append a space after the
completion. We can't complete "fie/live" or "fie/dead" without
first backspacing over that space.
We used to thus create two fake names, "fie/a" and "fie/b", to force
the shell to consider the completion to be ambiguous. It would then
stop at "fie/" without appending a space, allowing us to hit tab
again to complete "fie/live" or "fie/dead".
The change here arises from realising that we only need to force
the shell to consider a completion as ambiguous if we have exactly
one directory and zero files as possible completions.
This prevents spurious names from showing up as possible completions
when they don't need to be invented in the first place.
The bash_completion code uses "hg status" to generate a list of
possible completions for commands that operate on files in the
working directory. In a large working directory, this can result
in a single tab-completion being very slow (several seconds) as a
result of checking the status of every file, even when there is no
need to check status or no possible matches.
The new debugpathcomplete command gains performance in a few simple
ways:
* Allow completion to operate on just a single directory. When used
to complete the right commands, this considerably reduces the
number of completions returned, at no loss in functionality.
* Never check the status of files. For completions that really must
know if a file is modified, it is faster to use status:
hg status -nm 'glob:myprefix**'
Performance:
Here are the commands used by bash_completion to complete, run in
the root of the mozilla-central working dir (~77,000 files) and
another repo (~165,000 files):
All "normal state" files (used by e.g. remove, revert):
mozilla other
status -nmcd 'glob:**' 1.77 4.10 sec
debugpathcomplete -f -n 0.53 1.26
debugpathcomplete -n 0.17 0.41
("-f" means "complete full paths", rather than the current directory)
Tracked files matching "a":
mozilla other
status -nmcd 'glob:a**' 0.26 0.47
debugpathcomplete -f -n a 0.10 0.24
debugpathcomplete -n a 0.10 0.22
We should be able to further improve completion performance once
the critbit work lands. Right now, our performance is limited by
the need to iterate over all keys in the dirstate.
When completing a "label" (a symbolic name for a commit), the
bash_completion script currently has to invoke hg three times. For
a large repository, the cost of starting up and loading all the
necessary context over and over is very high.
For instance, in mozilla-central:
time (export HGPLAIN=1; hg tags -q; hg bookmarks -q; hg branches) >/dev/null
0.446 sec
Compare with the debuglabelcomplete command that this commit adds:
time hg debuglabelcomplete >/dev/null
0.148 sec
This greatly helps responsiveness.
After this change, moving the active bookmark somewhere other than the
current changeset (i.e., with --rev) deactivates it. Previously it would
remain in .hg/bookmarks.current, which seems like a bug.
Allow a bookmark that points to the current changeset to be made the
active bookmark without requiring --force. Previously, this would've
aborted with:
abort: bookmark 'Z' already exists (use -f to force)
Allow 'hg bookmark MARK', with an existing bookmark MARK, to move the
bookmark forward to the current or specified revision, if the target
revision is a descendant of the revision the bookmark currently points
to. Prints a status message including the revision the bookmark was
formerly at:
$ hg bookmark Z
moving bookmark 'Z' forward from 663762316562
Test coverage is added.
When a series of commits first adds a file and then removes it,
hg rebase --collapse prompts whether to keep the file or delete it. This is
due to it reusing the branch merge code. In a noninteractive terminal it
defaults to keeping the file, which results in a collapsed commit that is
has a file that should be deleted. This bug resulted in developers accidentally
commiting unintentional changes to our repo twice today, so it's fairly
important to get fixed.
This change allows rebase --collapse to tell the merge code to accept the
latest version every time without prompting.
Adds a test as well.
Since re2 is enormously faster than Python's re module, this should
help performance, ceteris paribus. grep currently has other huge
performance problems that mask any gain :-(
Writes the backup bundle paths to the blackbox so it's easy to see which
backup bundle is associated with which command when you are debugging an
issue.
Example output:
2013/03/13 10:39:56 durham> strip tip
2013/03/13 10:39:59 durham> saved backup bundle to /data/users/durham/www-hg/.hg/strip-backup/e5fac262363a-backup.hg
2013/03/13 10:40:03 durham> strip tip exited 0 after 7.97 seconds
hg strip -k was using dirstate.rebuild() which reset all the dirstate
entries timestamps to 0. This meant that the next time hg status was
run every file was considered to be 'unsure', which caused it to do
expensive read operations on every filelog. On a repo with >150,000
files it took 70 seconds when everything was in memory. From a cold
cache it took several minutes.
The fix is to only reset files that have changed between the working
context and the destination context.
For reference, --keep means the working directory is left alone during
the strip. We have users wanting to use this operation to store their
work-in-progress as a commit on a branch while they go work on another
branch, then come back later and be able to uncommit that work and
continue working. They currently use 'git reset HARD^' to accomplish
this in git.
When running 'hg pull --rebase', I was seeing this exception 100% of the
time as the python process was closing down:
Exception TypeError: TypeError("'NoneType' object is not callable",) in
<bound method Popen.__del__ of <subprocess.Popen object at 0x937c10>> ignored
By storing the subprocess on the sshpeer, the subprocess seems to clean up
correctly, and I no longer see the exception. I have no idea why this actually
works, but I get a 0% repro if I store the subprocess in self.subprocess,
and a 100% repro if I store None in self.subprocess.
Possibly related to issue 2240.
When running commands like 'hg export -o mypatch-%N.patch', the blackbox
would throw an exception because it tried to format %N. This change
prevents it from trying to format the command string.
When the web server shows the manifest for a single, non top directory, append
the path to the directory to the archive links. This makes the web server
generate archive files that only include the current directory (and its
subdirectories).
Note that archive links in other pages (e.g. changeset) or at the top of the
manifest are unchanged. Directory archive links have an extra "/" at the end
which does not impact the result of the archive operation. Keeping it there
made the implementation of this feature simpler.
The archive web command now takes into account the "file" request entry, if one
is provided.
The provided "file" is processed as a "path" corresponding to a directory or
file that will be downloaded.
With this change hgweb can to process requests such as:
http://mercurial.selenic.com/hg/archive/tip.zip/mercurial/templates
This will download all files on the mercurial/templates directory as a zip file.
It is not possible to specify file patterns ('glob', 'relglob', 'path',
'relpath', 're', 'relre' nor 'set'). The server will reject those with a
403 HTTP error response.
Note that this is a first step to add support for downloading directories from
the web interface. A following patch will modify the archiveentry map entry on
the different templates so that it adds the current folder path to the archive
links.
We move the logic for generating the unformatted ReST source to the
help module, in order to eventually avoid calling commands.help_()
from hgweb.
No functionality change.
I often want to measure the cost of a function call before/after
an optimization, where using top level "hg --time" timing introduces
enough other noise that I can't tell if my efforts are having an
effect.
This decorator allows a developer to measure a function's cost with
finer granularity.
The certificate was updated in March 2012.
You can verify the certificate by using the Root CA certificate downloadable
from https://ssl.intevation.de/
The intermediate CA is sent by https://hg.intevation.org/
This saves us a couple of dict lookups in the common case, and improves
the performance of the status method by 5% (measured with util.timed)
in a repo with a large manifest.
This improves the performance of log --patch and --stat by about
20% for moderately large manifests (e.g. mozilla-central) for the
common case of no -I/-X patterns.
Forgot to import util in mercurial.scmwindows. Error was introduced in:
changeset: 18862:bf7bac95e297
user: Kevin Bullock <kbullock@ringworld.org>
date: Tue Feb 12 11:36:21 2013 -0600
summary: scmutil: split platform-specific bits into their own modules
In a large repo, running a command like "log -l1 -p" was expensive because
it would always traverse 8 commits, as 8 was the initial window size.
We now choose the lesser of 8 or the limit, speeding up the "log -l1 -p"
case by a factor of 5.
We now wait for worker processes in a separate thread, so that we can
spot failures in a timely way, wihout waiting for the progress pipe
to drain.
If a worker fails, we recover the pre-parallel-update behaviour of
failing early by killing its peers before propagating the failure.
