The number of output lines was hardcoded to 30.
There was a 'nested' configuration options that controlled something else
related to counting the number of output lines.
This introduces the profiling.limit configuration option for controlling the
number of profiling output to show.
The slightly obscure --lfa and --lfc only worked as modifiers to --large and
could be combined. The documentation was however not clear what they did.
Instead they now imply --large and the description is updated.
Show messages at a point where the actions have been sorted, thus preparing for
backout of 14f4258e3526.
This makes manifestmerge more of a silent operation, just like 'copies' is.
Indent 'preserving' messages to make them subordinate to the action logging so
they fit in the new context. (The 'preserving' messages are quite redundant and
could also be removed completely.)
Preparing for backout of 14f4258e3526.
The number of prompts will for all relevant cases be significantly smaller than
the total number of files in the manifests. We can thus afford to sort the
prompts more than we can afford to sort the manifests.
If there is an active bookmark while committing, the bookmark name
will be visible inside the commit message helper, below the branch
name.
This should make easier for the user to detect a mistaken commit
parent, while working for example with a bookmark centric workflow
like topic branches.
The active bookmark is checked to be in the working directory, as
pointed by Kevin Bullock, because otherwise committing would not
advance it. In other words, this would not show the active
bookmark name if the user changed the working tree parents with
'hg debugsetparents', for example.
Adding support to parsedate in util module to understand the more idiomatic
dates 'today' and 'yesterday'.
Added unified tests and docstring tests for added functionality.
Change ancestor to accept 0 or more arguments. The greatest common ancestor of a
single changeset is that changeset. If passed no arguments, the empty list is
returned.
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}
This changeset adds a small mention of it in the help to prevent
confusion. This small addition references online help that is easier to
update and improve at release time.
Following Wagner Bruna's advice, this is added in a plain new paragraph
to not invalidate current translation this close to the release.
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.
Mention that Mercurial helps you not do what you've just been warned not
to do, with a reference to the 'phases' help topic (not the 'phase'
command help).
Thanks to Pierre-Yves David <pierre-yves.david@ens-lyon.org> for
motivating this change and Wagner Bruna
<wagner.bruna+mercurial@gmail.com> for advising on how to do it in an
i18n-friendly way.
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.
test-http-proxy.t sometimes failed with:
File ".../tests/tinyproxy.py", line 110, in _read_write
data = i.recv(8192)
error: (104, 'Connection reset by peer')
This might have started showing up with 9eb533d10f1a ... but it has apparently
also been seen before. I don't see anything in 9eb533d10f1a that can explain
it. It seems to be a race in test, in the tinyproxy helper:
Tinyproxy found an incoming socket using select(). It would break the loop if
an error had been detected on the socket, but there was no error and it tried
to recv() from the socket. That failed - apparently because it had been reset
after select().
Errors in the recv() will now be caught and will break the loop like errors
detected by select() would.
(send() could also fail in a similar way ... but using the same solution there
and losing data we have read doesn't feel right.)
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.
If the binary hash of the parent node guessed via --outgoing happened
to contain a special revset character (":" was specified in the bug),
the revset parser would abort. Hexlifying the node before passing it
to the revsingle call should fix that.
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.
This makes it possible to fix the seed by using for instance
PYTHONHASHSEED=7 ./run-tests.py ...
This can be very convenient when trying to debug problems that are influenced
by hash values. Try different seed values until you find one that triggers the
bad behaviour and then keep that while debugging.
The value 0 will restore default Python behavior and disable randomization.
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.
