We can't (easily) force SSL version on older Pythons, but on 2.6 and
later we can force SSLv3, which is safer and widely supported. This
also appears to work around a bug in IIS detailed in issue 3905.
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+.
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, 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.
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.
When a subrepo has changed on the local and remote revisions, prompt the user
whether it wants to merge those subrepo revisions, keep the local revision or
keep the remote revision.
Up until now mercurial would always perform a merge on a subrepo that had
changed on the local and the remote revisions. This is often inconvenient. For
example:
- You may want to perform the actual subrepo merge after you have merged the
parent subrepo files.
- Some subrepos may be considered "read only", in the sense that you are not
supposed to add new revisions to them. In those cases "merging a subrepo" means
choosing which _existing_ revision you want to use on the merged revision. This
is often the case for subrepos that contain binary dependencies (such as DLLs,
etc).
This new prompt makes mercurial better cope with those common scenarios.
Notes:
- The default behavior (which is the one that is used when ui is not
interactive) remains unchanged (i.e. merge is the default action).
- This prompt will be shown even if the ui --tool flag is set.
- I don't know of a way to test the "keep local" and "keep remote" options (i.e.
to force the test to choose those options).
# HG changeset patch
# User Angel Ezquerra <angel.ezquerra@gmail.com>
# Date 1378420708 -7200
# Fri Sep 06 00:38:28 2013 +0200
# Node ID 2fb9cb0c7b26303ac3178b7739975e663075857d
# Parent 796d34e1b749b79834321ef1181ed8433a5515d9
merge: let the user choose to merge, keep local or keep remote subrepo revisions
When a subrepo has changed on the local and remote revisions, prompt the user
whether it wants to merge those subrepo revisions, keep the local revision or
keep the remote revision.
Up until now mercurial would always perform a merge on a subrepo that had
changed on the local and the remote revisions. This is often inconvenient. For
example:
- You may want to perform the actual subrepo merge after you have merged the
parent subrepo files.
- Some subrepos may be considered "read only", in the sense that you are not
supposed to add new revisions to them. In those cases "merging a subrepo" means
choosing which _existing_ revision you want to use on the merged revision. This
is often the case for subrepos that contain binary dependencies (such as DLLs,
etc).
This new prompt makes mercurial better cope with those common scenarios.
Notes:
- The default behavior (which is the one that is used when ui is not
interactive) remains unchanged (i.e. merge is the default action).
- This prompt will be shown even if the ui --tool flag is set.
- I don't know of a way to test the "keep local" and "keep remote" options (i.e.
to force the test to choose those options).
This causes httpclient to use the same SSL settings as the rest of
Mercurial, and adds an easy extension point for later modifications to
our ssl handling.
This lets us inject our own ssl.wrap_socket equivalent into
httpclient, which means that any changes we make to our ssl handling
can be *entirely* on our side without having to muck with httpclient,
which sounds appealing. For example, an extension could wrap
sslutil.ssl_wrap_socket with an api-compatible wrapper and then tweak
SSL settings more precisely or use GnuTLS instead of OpenSSL.
Prior to this change, we default to SSLv23, which is insecure because
it allows use of SSLv2. Unfortunately, there's no constant for OpenSSL
to let us use SSLv3 or TLS - we have to pick one or the other. We
expose a knob to revert to pre-TLS SSL for the user that has an
ancient server that lacks proper TLS support.
Previously, the error message for a dirty non-linear update was the same (and
relatively unhelpful) whether or not a rev was specified. This patch and an
upcoming one will introduce separate, more helpful hints.
While the default mode appends all the new entries to a container on the page,
the graph mode resizes canvas correctly, and repaints the graph to include
newly received data.
Namely, this allows the next page pointer to be not only revision hash given
in page code, but also any value computed from the value for previous page.
Before this patch, all localrepositories support same features,
because supported features are managed by the class variable
"supported" of "localrepository".
For example, "largefiles" feature provided by largefiles extension is
recognized as supported, by adding the feature name to "supported" of
"localrepository".
So, commands handling multiple repositories at a time like below
misunderstand that such features are supported also in repositories
not enabling corresponded extensions:
- clone/pull from or push to localhost
- recursive execution in subrepo tree
"reposetup()" can't be used to fix this problem, because it is invoked
after checking whether supported features satisfy ones required in the
target repository.
So, this patch adds the set object named as "featuresetupfuncs" to
"localrepository" to manage hook functions to setup supported features
of each repositories.
If any functions are added to "featuresetupfuncs", they are invoked,
and information about supported features is managed in each
repositories individually.
This patch also adds checking below:
- pull from localhost: whether features supported in the local(= dst)
repository satisfies ones required in the remote(= src)
- push to localhost: whether features supported in the remote(= dst)
repository satisfies ones required in the local(= src)
Managing supported features by the class variable means that there is
no difference of supported features between each instances of
"localrepository" in the same Python process, so such checking is not
needed before this patch.
Even with this patch, if intermediate bundlefile is used as pulling
source, pulling indirectly from the remote repository, which requires
features more than ones supported in the local, can't be prevented,
because bundlefile has no information about "required features" in it.
Before this patch, "extensions.extensions()" always lists up all
loaded extensions. So, commands handling multiple repositories at a
time like below enable extensions unexpectedly.
- clone from or push to localhost: extensions enabled only in the
source are enabled also in the destination
- pull from localhost: extensions enabled only in the destination
are enabled also in the source
- recursive execution in subrepo tree: extensions enabled only in
the parent or some of siblings in the tree are enabled also in
others
In addition to it, extensions disabled locally may be enabled
unexpectedly.
This patch checks whether each of extensions should be listed up or
not, if "ui" is specified to "extensions.extensions()", and invokes
"reposetup()" of each extensions only for repositories enabling it.
This makes it possible to make keyword search in case the search query also
specifies an exact revision (like '1234' or 'abcdef'), or a revset expression.
This function should be correctly called on a page, otherwise there is
no effect.
When called, it makes ajax requests for the next portion of changesets when the
user scrolls to the end. Also, when the monitor is high so that the
default amount of changesets isn't enough to fill it, multiple portions are
loaded if needed after the page load.
This function performs an asynchronous HTTP request and calls provided
callbacks:
- onstart: request is sent
- onsuccess: response is received
- onerror: some error occured
- oncomplete: response is fully processed and all other callbacks finished
Get the whole list of entries before rendering instead of using lazy evaluation.
This doesn't affect the performance for usual case when the entries are shown
anyway. When both entries and latestentry are used, this performs unnoticeably
faster, and for pages which use only latestentry (quite uncommon case) it
would be a bit slower.
This change will make it possible to get the first entry of the next page easily
without computing the list twice.
Running "hg log <pattern or directory>" on large repos took a very, very long
time because it first read ctx.files() for every commit before even starting to
process the results.
This change makes the ctx.files() check lazy, which makes the command start
producing results immediately.
memchr is usually smarter than a simple for loop. With gcc 4.4.6 and glibc 2.12
on x86-64, for a 20 MB, 200,000 file manifest, parse_manifest goes from 0.116
seconds to 0.095 seconds.
This mode is used when all the conditions are met:
- 'reverse(%s)' % query string can be parsed to a revset tree
- this tree has depth more than two, i.e. the query has some part of
revset syntax used
- the repo can be actually matched against this tree, i.e. it has only existent
function/operators and revisions/tags/bookmarks specified are correct
- no revset regexes are used in the query (strings which start with 're:')
- only functions explicitly marked as safe in revset.py are used in the query
Add several new tests for different parsing conditions and exception handling.
In case we don't have a cached text already, add the base rev to the list
passed to _chunks. In the cached case this also avoids unnecessarily preloading
the chunk for the cached rev.
We do this in a somewhat hacky way, relying on the fact that our sole caller
preloads the cache right before calling us. An upcoming patch will make this
more sensible.
For a 20 MB manifest with a delta chain of > 40k, perfmanifest goes from 0.49
seconds to 0.46.
Previously the length of data preloaded did not account for the interleaved io
contents. This meant that we'd sometimes have cache misses in _chunks despite
the preloading.
Having a correctly filled out cache will become essential in an upcoming patch.
This moves _chunkraw into the loop. Doing that improves revlog decompression --
in particular, manifest decompression -- significantly. For a 20 MB manifest
which is the result of a > 40k delta chain, hg perfmanifest improves from 0.55
seconds to 0.49 seconds.
Currently, we have basectx that serves as a common ancestor of all contexts. We
will now add a new class commitablectx that will inherit from basectx and will
serve as a common place for code that will be shared between mutable contexts,
e.g. workingctx and memctx.
Full walks are only necessary when the caller needs the list of clean files.
addremove by definition doesn't need them.
With this patch and an extension that produces a subset of results for
dirstate.walk when full is False, on a repository with over 200,000 files, hg
addremove drops from 2.8 seconds to 0.5.
Previously we'd place files written in the last second in the lookup set. This
can lead to pathological cases where a file always remains in the lookup set if
it gets modified before the next time status is run.
With this patch, only the mtime of those files is invalidated. This means that
if a file's size or mode changes, we can immediately declare it as modified
without needing to compare file contents.
On Windows, there are two ways symlinks can manifest themselves:
1. As placeholders: text files containing the symlink's target. This is what
usually happens with fresh clones on Windows.
2. With their dereferenced contents. This happens with clones accessed over NFS
or Samba.
In order to handle case 2, 28af3e0c54f0 made dirstate.status ignore all symlink
placeholders on Windows. It doesn't ignore symlinks in the lookup set, though,
since those don't have the link bit set. This is problematic because it
violates the invariant that `hg status` with every file in the normal set
produces the same output as `hg status` with every file in the lookup set.
With this change, symlink placeholders in the normal set are no longer ignored.
We instead rely on code in localrepo.status that uses heuristics to look for
suspect placeholders.
An upcoming patch will test this out by no longer adding files written in the
last second of an update to the lookup set.
A symlink's target should never be empty in normal use. Solaris and some BSDs
do allow empty symlinks to be created (with varying semantics on dereference),
but a symlink placeholder that started off as empty is either
- going to be empty, in which case ignoring it is fine, since it's unchanged, or
- going to not be empty, in which case this check is irrelevant.
This adds the ability to specify a config option, ui.debugger, to a custom pdb
module, such as ipdb, and have mercurial use that as its debugger. As long as
the value of ui.debugger is a loadable module with the set_trace and
post_mortem functions, then dispatch will be able to use the custom module.
Debugging _parseconfig is still available in the case of an error since it will
be caught with a default the value of pdb.post_mortem.
Previously, command line parsing of --config arguments was done in
_dispatch. This means that it takes place after activating the debugger. In an
upcoming patch, we will add a ui.debugger setting so we need to have this
parsing done before _runcatch.
This will be useful when reusing submerge() to improve the handling of subrepos
on mq.
# HG changeset patch
# User Angel Ezquerra <angel.ezquerra@gmail.com>
# Date 1377117244 -7200
# Wed Aug 21 22:34:04 2013 +0200
# Node ID 2defb5453f223c3027eb2f7788fbddd52bbb3352
# Parent a5c90acff5e61aae714ba6c9457d766c54b4f124
subrepo: make submerge() return the merged substate
This will be useful when reusing submerge() to improve the handling of subrepos
on mq.
This changes the behavior for queries which point at a revision directly,
now the output is consistent to other cases: it results in only this matched
revision shown, not the log starting with it.
A new test checks this behaviour and fails for the old one.
This changes makes clearer which arguments can a function depend on. Now all
the modified functions depend on the 'query' argument only, but future additions
will change it.
This makes possible to use unionrevlog class with subclasses of revlog that
override revlog's 'revision' and 'revdiff' methods. In particular this change
is necessary to implement manifest compression, as it allows extension to
replace manifest class and override 'revision' amd 'revdiff' methods there.
This makes possible to use bundlerevlog class with subclasses of revlog
that override revlog's 'revision' method. In particular this change is necessary
to implement manifest compression, as it allows extension to replace manifest
class and override 'revision' method there.
This change will allow revlog subclasses that override 'checkhash' method
to use custom strategy of computing nodeids without overriding 'addrevision'
method. In particular this change is necessary to implement manifest
compression.
Extract method that decides whether nodeid is correct for paricular revision
text and parent nodes. Having this method extracted will allow revlog
subclasses to implement custom way of computing nodes. In particular this
change is necessary to implement manifest compression.
After a day of hunting this defect, I'm now unable to reproduce the
bug without this patch applied. Regardless, this should fix the
problem I was observing with wireshark. Hopefully this fixes any
flakiness in the buildbot from http2.
We change the hardcoded 'filectx' to instead use type(self).__name__ so that objects that
inherit from basefilectx in the future will be able to use the same representation.
Similar to the refactoring of context, we split common logic from filectx to a
parent class called basefilectx that will be inherited by filectx,
workingfilectx, and memfilectx. This will allow a clear disinction of all the
file contexts:
- filectx: read-only access to a filerevision that is already present in the repo,
- workingfilectx: a filecontext that represents files from the working directory,
- memfilectx: a filecontext that represents files in-memory
The refactoring of all the context objects allows us to simply pass a basectx
to the __new__ constructor and have it return the same object without
allocating new memory.
The refactoring of all the context objects allows us to simply pass a basectx
to the __new__ constructor and have it return the same object without
allocating new memory.
We change the hardcoded 'changectx' to instead use type(self).__name__ so that
objects that inherit from basectx in the future will be able to use the same
representation.
At the moment, there is no simple way to check if an object is a context
because there is no common parent class. If there were, we could use
'isinstance' everywhere. Simply having memctx inherit from workingctx or
changectx would allow the use of 'isinstance' but that could lead to some
confusing situations of reading the code since we have three distinct concepts
of a context:
- changectx represents a changeset *already* in the repo, and is therefore immutable
- workingctx represents changes on disk in the working directory
- memctx represents changes solely in memory which may or may not be on disk
Therefore, I propose refactoring context.py to have all three contexts inherit
from a parent class 'basectx'.
Not all WSGI servers close the socket when an early response is sent
to a large POST request, which can cause the server to interpret the
already-sent request body as an incoming (but hopelessly invalid)
request.
Actual amount of revisions is used now instead of their numbers in the repo
before to deal with skipped numbers correctly.
This iterates starting from the newest revision (which is shown on top)
yielding up to the specified count, instead of the reversed order used before.
Effect of this change on efficiency is negligible, when the same changesets are
returned.
It is the same fix for graph command, as was recently for log. This makes the
specified revision be always on top of the graph view.
Before the patch, for example with repo having revisions 0, 1, 2, 3 and revision
in url being '2', all revisions were shown and the specified one wasn't
the first.
