This function looped over every node due to getElementsByTagName('*'), instead
of using selectors. In this patch we use querySelectorAll('.age') and process
only these nodes, which is much faster and also doesn't require extra condition.
Browser compatibility isn't sacrificed: IE 8+, FF 3.5+, Opera 10+.
We allow shelving of of changes on top of a MQ repository. MQ will
not allow repository changes on top of applied patches. We introduce
checkapplied in MQ to bypass this check.
Use a more condensed and mercurial-like output format for shelve listing.
We don't prefix the message with 'shelved from...' anymore as our default
name contains the branch name or the user used his own name. To avoid
just printing the last commit message, we drop writing the description
to stdout.
old output:
default [1s ago] shelved from default (01ba9745): create conflict
new output:
default (1s ago) create conflict
This extension saves shelved changes using a temporary draft commit,
and bundles the temporary commit and its draft ancestors, then
strips them.
This strategy makes it possible to use Mercurial's bundle and merge
machinery to resolve conflicts if necessary when unshelving, even
when the destination commit or its ancestors have been amended,
squashed, or evolved. (Once a change has been unshelved, its
associated unbundled commits are either rolled back or stripped.)
Storing the shelved change as a bundle also avoids the difficulty
that hidden commits would cause, of making it impossible to amend
the parent if it is a draft commits (a common scenario).
Although this extension shares its name and some functionality with
the third party hgshelve extension, it has little else in common.
Notably, the hgshelve extension shelves changes as unified diffs,
which makes conflict resolution a matter of finding .rej files and
conflict markers, and cleaning up the mess by hand.
We do not yet allow hunk-level choosing of changes to record.
Compared to the hgshelve extension, this is a small regression in
usability, but we hope to integrate that at a later point, once the
record machinery becomes more reusable and robust.
repo.transaction always writes to stderr when a transaction aborts. In order to
be able to abort a transaction quietly (e.g shelve needs a temporary view on
the repo) we need to make the report level configurable.
Before this patch, "hg summary" may fail, when there is inconsistent
rebase state: for example, the root of rebase destination revisions
recorded in rebase state file is already stripped manually.
Mercurial earlier than 2.7 allows users to do anything other than
starting new rebase, even though current rebase is not finished or
aborted yet. So, such inconsistent rebase states may be left and
forgotten in repositories.
This patch catches RepoLookupError at restoring rebase state for
summary hook, and treat such state as "broken".
Before this patch, "rebase --abort"/"--continue" may fail, when rebase
state is inconsistent: for example, the root of rebase destination
revisions recorded in rebase state file is already stripped manually.
Mercurial earlier than 2.7 allows users to do anything other than
starting new rebase, even though current rebase is not finished or
aborted yet. So, such inconsistent rebase states may be left and
forgotten in repositories.
This patch catches RepoLookupError at restoring rebase state for
abort/continue, and treat such state as "broken".
Mercurial earlier than 2.7 allows users to do anything other than
starting new histedit, even though current histedit is not finished or
aborted yet. So, unfinished (and maybe inconsistent now) histedit
states may be left and forgotten in repositories.
Before this patch, histedit extension shows the message below, when it
detects such inconsistent state:
abort: REV is not an ancestor of working directory
(update to REV or descendant and run "hg histedit --continue" again)
But this message is incorrect, unless old Mercurial is re-installed,
because Mercurial 2.7 or later disallows users to update the working
directory to another revision.
This patch changes the hint message to suggest "hg histedit --abort".
Before this patch, pushing with --new-branch permits to create
multiple headed branch on the destination repository.
But permitting to create new branch should be different from
permitting to create multiple heads on branch.
This patch prevents from careless pushing multiple headed new branch,
and requires --force to push such branch forcibly.
Since repoview in 2.5 we do not make special call to `branchmap` when stripping.
We just recompute the branchmap from a lower subset that still has valid
branchmap. So I'm dropping this dead code.
It was unused. note how it is only extended if the list is empty. So it's always
empty at the end.
We could try to fix that, however this would part of the code is to be removed
in the next changeset as we do not run `branchmap` on truncated repo since
`repoview` in 2.5.
Before this patch, if there are multiple roots in "--outgoing"
revisions, result of "histedit --outgoing" depends on the parent of
the working directory. It succeeds only when the parent of the working
directory is a descendant of the oldest root in "--outgoing"
revisions, and fails otherwise.
It seems to be ambiguous and difficult for users.
This patch makes "histedit --outgoing" abort if there are multiple
roots in "--outgoing" revisions always.
Before this patch, if there are multiple roots in "--outgoing"
revisions, result of "histedit --outgoing" depends on the parent of
the working directory. It succeeds only when the parent of the working
directory is a descendant of the oldest root in "--outgoing"
revisions, and fails otherwise.
It seems to be ambiguous and difficult for users.
This patch makes "histedit --outgoing" abort if there are multiple
roots in "--outgoing" revisions always.
A `unfilteredpropertycache` is a kind of `propertycache` used on `localrepo` to
unsure it will always be run against unfiltered repo and stored only once.
As the cached value is never stored in the repoview instance, the descriptor
will always be called. Before this patch such calls always result in a call to
the `__get__` method of the `propertycache` on the unfiltered repo. That was
recomputing a new value on every access through a repoview.
We can't prevent the repoview's `unfilteredpropertycache` to get called on every
access. In that case the new code makes a standard attribute access to the
property. If a value is cached it will be used.
The `propertycache` test file have been augmented with test about this issue.
Propertycache used standard attribute assignment. In the repoview case, this
assignment was forwarded to the unfiltered repo. This result in:
(1) unfiltered repo got a potentially wrong cache value,
(2) repoview never reused the cached value.
This patch replaces the standard attribute assignment by an assignment to
`objc.__dict__` which will bypass the `repoview.__setattr__`. This will not
affects other `propertycache` users and it is actually closer to the semantic we
need.
The interaction of `propertycache` and `repoview` are now tested in a python
test file.
Before this patch, "hg help -k KEYWORD" fails, if there is the
extension of which name includes ".", because "extensions.load()"
invoked from "help.topicmatch()" fails to look such extension up, even
though it is already loaded in.
"help.topicmatch()" invokes "extensions.load()" with the name gotten
from "extensions.enabled()". The former expects full name of extension
(= key in '[extensions]' section), but the latter returns names
shortened by "split('.')[-1]". This difference causes failure of
looking extension up.
This patch adds "shortname" argument to "extensions.enabled()" to make
it return shortened names only if it is True. "help.topicmatch()"
turns it off to get full name of extensions.
Then, this patch shortens full name of extensions by "split('.')[-1]"
for showing them in the list of extensions.
Shortening is also applied on names gotten from
"extensions.disabled()" but harmless, because it returns only
extensions directly under "hgext" and their names should not include
".".
Previously basecache was incorrectly initialized before adding the first
revision from a changegroup. Basecache value influences when full revisions are
stored in revlog (when using generaldelta). As a result it was possible to
generate a generaldelta-revlog that could be bigger by arbitrary factor than its
non-generaldelta equivalent.
Python docs are a little unclear, but mpm reports reading the OpenSSL
source code shows that PROTOCOL_SSLv23 allows TLS whereas
PROTOCOL_SSLv3 does not.
Somewhere before 2.7, a change [82beb9b16505] was committed that
entailed a large performance regression when bundling (and therefore
remote cloning) repositories. For each file in the repository, it would
recompute the set of needed changesets even though it is the same for
all files. This computation would dominate bundle runtimes according to
profiler output (by 10x or more).
getbe32 and putbe32 need to behave differently on big-endian and little-endian
systems. On big-endian ones, they should be roughly equivalent to the identity
function with a cast, but on little-endian ones they should reverse the order
of the bytes. That is achieved by the original definition, but
__builtin_bswap32 and _byteswap_ulong, as the names suggest, swap bytes around
unconditionally.
There was no measurable performance improvement, so there's no point adding
extra complexity with even more ifdefs for endianncess.
Strip now lives in its own extension
reminder: The extension is surprisingly called `strip`. The `mq` extension
force the use of the strip extension when its enabled. This is both necessary
for backward compatibility (people expect `mq` to comes with strip) and become
some utility function used by `mq` are now in the strip extension.
Strip will lives in its own extension. The extension is surprisingly called
`strip`. (as discussed in issue3824) The `mq` extension force the use of the
strip extension when its enabled. This will both necessary for backward
compatibility (people expect `mq` to comes with strip) and become some utility
function used by `mq` will move in the strip extension.
This is the last step before being able to extract `strip` in its own extension.
The changes are made in mq to allow a move only extraction without touching a
line of code.
Same as in the previous changeset, rev is never `None`. We can just copy the two
relevant lines in in `queue.strip`. This help having `queue.strip` independent
from `queue`. One further step toward the extraction of `strip` in an independent
extension. (As discussed in issue3824).
In this case, rev is never `None`. We can just copy the two relevant lines in
in `strip`. This help having `strip` independent from `queue` one
further step toward its extraction in an independent extension. (As
discussed in issue3824).
