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.
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.
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.
