Vaguely empirical observations:
* ".py" tests are about an order of magnitude faster than ".t" tests
* dividing size by 1000 gives an approximation to wall-clock
run time (in seconds) that is not completely ridiculous.
I recently implemented the server.bundle1* options to control whether
bundle1 exchange is allowed.
After thinking about Mozilla's strategy for handling generaldelta
rollout a bit more, I think server operators need an additional
lever: disable bundle1 if and only if the repo is generaldelta.
bundle1 exchange for non-generaldelta repos will not have the potential
for CPU explosion that generaldelta repos do. Therefore, it makes sense
for server operators to continue to allow bundle1 exchange for
non-generaldelta repos without having to set a per-repo hgrc option
to change the policy depending on whether the repo is generaldelta.
This patch introduces a new set of options to control bundle1 behavior
for generaldelta repos. These options enable server operators to limit
bundle1 restrictions to the class of repos that can be performance
issues. It also allows server operators to tie bundle1 access to store
format. In many server environments (including Mozilla's), legacy repos
will not be generaldelta and new repos will or might be. New repos often
aren't bound by legacy access requirements, so setting a global policy
that disallows access to new/generaldelta repos via bundle1 could be a
reasonable policy in many server environments. This patch makes this
policy very easy to implement (modify global hgrc, add options to
existing generaldelta repos to grandfather them in).
It seems like a good idea to document the revlog format.
There is a lot more that could be added to this documentation.
But you have to start somewhere.
Expose afterresolvedstates to allow graft and similar to
suggest a message when resolving results in no unresolved
files.
If there isn't a matching state in afterresolvedstates,
then if verbose, suggest commiting.
While I was here, some single element tuples have been removed in
favor of the shorter syntax. Some commented lines of code containing
print statements have also been removed because it was unclear what
purpose they served.
Previously, we were using Python's native 'os.path.isfile' method which follows
symlinks. In this case, since we're operating on repo contents, we don't want
to follow symlinks.
There's a behaviour change here, as shown by the second part of the added test.
Consider a symlink 'f' pointing to a file containing 'abc'. If we try and
replace it with a file with contents 'abc', previously we would have let it
though. Now we don't. Although this breaks naive inspection with tools like
'cat' and 'diff', on balance I believe this is the right change.
This enhances proxy support in httpclient a little bit, though I don't
know that we used that functionality at all. It also switches httpplus
to using absolute_import.
This effectively backs out 163c899d1e46 and f44b0edaab90.
We can't handle "default-push" just like "default:pushurl" because it is a
stand-alone named path. Instead, I have two ideas to work around the issue:
a. two defaults: getpath(dest, default=('default-push', 'default'))
b. virtual path: getpath(dest, default=':default')
(a) is conservative approach and will have less trouble, but callers have
to specify they need "default-push" or "default". (b) generates hidden
":default" path from "default" and "default-push", and callers request
":default". This will require some tricks and won't work if there are
conflicting sub-options valid for both "pull" and "push".
I'll take (a) for default branch. This patch should NOT BE MERGED to default
except for tests because it would break handling of "pushurl" sub-option.
It makes far more sense to leave these conflicts unresolved and kick back to
the user than to just assume that the local version be chosen. There are almost
certainly buggy scripts and applications using Mercurial in the wild that do
merges or rebases non-interactively, and then assume that if the operation
succeeded there's nothing the user needs to pay attention to.
(This wasn't possible earlier because there was no way to re-resolve
change/delete conflicts -- but now it is.)
This adds a test extension to check that the non-normal set contains the
expected entries. It wraps several methods of the dirstate to check that
the non-normal set has the correct values before and after the call. The
extension lives in contrib so that paranoid developers can easily
enable it to make sure that the non-normal set is consistent across more
complex operations than the included tests.
Previous patch introduced 'revset.predicate' decorator to register
revset predicate function easily.
But it shouldn't be used in extension directly, because it registers
specified function immediately. Registration itself can't be restored,
even if extension loading fails after that.
Therefore, registration should be delayed until 'uisetup()' or so.
This patch uses 'extpredicate' decorator derived from 'delayregistrar'
to register predicate in extension easily.
This patch also tests whether 'registrar.delayregistrar' avoids
function registration if 'setup()' isn't invoked on it, because
'extpredicate' is the first user of it.
We now have sub-topics in the help system. The "helptopics" template
serves as a mechanism for displaying an index of help topics.
Previously, it was only used to show the top-level list of help topics,
which includes special groupings of topics.
In the near future, we'll adapt "helptopics" for showing the index
of sub-topics. In this patch, we optionally render {earlycommands} and
{othercommands} since they aren't present on sub-topics.
Before this patch, when rebasing a set of obsolete revisions that were plain
pruned or already present in the destination, we were displaying:
abort: no matching revisions
This was not very helpful to understand what was going on, instead we replace
the error message by:
abort: all requested changesets have equivalents or were marked as obsolete
(to force the rebase, set the config experimental.rebaseskipobsolete to False)
This diff implements the standard dict copy() method for lrucachedicts, which
will be used in the pushrebase extension to make a copy of the manifestcache.
Before this patch, "hg qimport -r REV" fails, if the summary line of
description of REV doesn't contain any alpha-numeric bytes.
In this case, all bytes in the summary line 'title' are dropped from
'namebase' by the code path below.
namebase = re.sub('[\s\W_]+', '_', title.lower()).strip('_')
'makepatchname()' immediately returns this empty string as valid patch
name, because patch name conflicting against empty string never
exists.
Then, "hg qimport -r REV" is aborted at creation of patch file with
empty filename.
This situation isn't so rare. For example, ordinary texts in Japanese
often consist of non alpha-numeric bytes in UTF-8.
This patch makes 'makepatchname()' use fallback patch name if the
summary line of imported revision doesn't contain any alpha-numeric
bytes.
This came up before, but the tests in check-code.py don't find -U (only -u)
and they don't work when the diff is inside a shell function. This fixes
the offending tests and beefs up check-code.py.
Danek's patch will help us avoid spurious test breakages on
Solaris. This test wasn't broken on Solaris because of the grep(1)
use, but it will upset check-code. Use cmp to silence check-code since
it doesn't matter.
currently "subscribe to atom feed" link in file log page is as follows.
/atom-log/[revision]/[file]
This is invalid, because we could not get newer commit feed than [revision].
To fix this, atom-log feed url should be the following style.
atom-log/tip/[file]
