Home - Waterfall Grid T-Grid Console Builders Recent Builds Buildslaves Changesources - JSON API - About

Console View

Legend:   Passed Failed Failed Again Running Exception Offline No data

3f234db6fe8d... timelessohnoyoudont@mozdev.org
test-help: verify that extension keywords appear in help templates

fixed by a2291c9c85a1
Matt Harbison
templatekw: add {changes}, {distance} and {tag} to the {latesttag} keyword
Matt Harbison
templater: introduce {latesttag()} function to match a pattern (issue4184)

This allows the latest class of tag to be found, such as a release candidate or
final build, instead of just the absolute latest.

It doesn't appear that the existing keyword can be given an optional argument.
There is a keyword, function and filter for 'date', so it doesn't seem harmful
to introduce a new function with the same name as an existing keyword.  Most
functions are pretty Mercurial agnostic, but there is {revset()} as precedent.

Even though templatekw.getlatesttags() returns a single tuple, one entry of
which is a list, it is simplest to present this as a list of tags instead of a
single item, with each tag having a distance and change count attribute.  It is
also closer to how {latesttag} returns a list of tags, and how this function
works when not given a '%' operator.
Matt Harbison
templatekw: introduce showlatesttags() to handle {latesttag} keywords

The keywords {changes}, {distance} and {tag} will be available on a future
template method that will allow pattern matching against tag names.  For
consistency, these should be available on the existing {latesttag} keyword as

I debated whether or not to add {tag} instead of just continuing with the
existing {latesttag}.  But it seems clearer not to have the same name for two
distinct things (a list in the LHS of %, and an individual tag value on the

The value of latesttags[0] is the date of commit for the cset to which the tag
is applied (i.e. not the date the tag was applied), and therefore isn't made
visible because it doesn't seem interesting.  It appears that this is merely an
internal implementation detail for sorting csets in a stable manner when there
are different branches.
Matt Harbison
templatekw: factor out the changessincetag calculation to a private method

This will be reused in the next patch.
Matt Harbison
templatekw: allow getlatesttags() to match a specific tag pattern

This will allow the latest class of tag to be found, such as a release candidate
or final build, instead of just the absolute latest.  It will be exposed in a
future patch.

It's unfortunate that the original 'latesttags' cache can't be used to determine
the proper values, but it isn't fully populated for the entire repo.  For
example, the {latesttagdistance} keyword on the Mecurial repo builds the cache
up back to the revision for 1.4.  If the pattern was 're:^0\.\d$', that wouldn't
be in the cache.  Maybe this can be optimized some other way, but for now, this
is the simpliest implementation.
Matt Harbison
util: extract stringmatcher() from revset

This is used to match against tags, bookmarks, etc in revsets.  It will be used
in a future patch to do the same tag matching in templater.
Gregory Szorc
util.chunkbuffer: avoid extra mutations when reading partial chunks

Previously, a read(N) where N was less than the length of the first
available chunk would mutate the deque instance twice and allocate a new
str from the slice of the existing chunk. Profiling drawed my attention
to these as a potential hot spot during changegroup reading.

This patch makes the code more complicated in order to avoid the
aforementioned 3 operations.

On a pre-generated mozilla-central gzip bundle, this series has the
following impact on `hg unbundle` performance on my MacBook Pro:

before: 358.21 real      317.69 user        38.49 sys
after:  301.57 real      262.69 user        37.11 sys
delta:  -56.64 real      -55.00 user        -1.38 sys
Gregory Szorc
util.chunkbuffer: refactor chunk handling logic

This will make the next patch easier to read. It provides no benefit on
its own.
Gregory Szorc
util.chunkbuffer: special case reading everything

The new code results in simpler logic within the while loop. It is also
faster since we avoid performing operations on the queue and buf
collections. However, there shouldn't be any super hot loops for this
since the whole point of chunkbuffer is to avoid reading large amounts
of data at once. This does, however, make it easier to optimize
chunkbuffer in a subsequent patch.
Mathias De Maré
revert: add reference to backout
Mathias De Maré
backout: add reference to revert
Siddharth Agarwal
localrepo: allow wlock to be inherited

This is part of a series that will allow locks to be inherited by subprocesses
in limited circumstances.

When allowed, the parent process will pass down requisite information to the
child process by way of this environment variable.
Siddharth Agarwal
lock.release: don't call postrelease functions for inherited locks

Review feedback from Pierre-Yves David. The postrelease functions typically
assume the lock is not held at all.
Siddharth Agarwal
lock: turn prepinherit/reacquire into a single context manager

Review feedback from Pierre-Yves David. This makes the overall code cleaner and
less error-prone, and makes a previously explicitly checked error state
Siddharth Agarwal
localrepo: add a note about parentenvvar

Review feedback from Pierre-Yves David.
Gregory Szorc
exchange: add "streaming all changes" to bundle2 pulling

This is the beginning of client-side support for performing a stream
clone using bundle2. The main bundle2 pull function checks whether to
perform a streaming clone and outputs a message if so.

While we have a duplicate message, it seems easier to have all the
bundle2 console writing in one location and in an easy-to-read
conditional block.
Gregory Szorc
streamclone: move "streaming all changes" message location

Previously, the message was printed after we requested and started
processing the remote stream. This seems like something that we should
do before calling out to the remote. Moving it also makes it easier to
deal with the bundle2 implementation.
Gregory Szorc
streamclone: move payload header generation into own function

The stream clone data over the wire protocol contains a header line
indicating total file count and data size. In bundle2, this metadata can
be captured by a part parameter and doesn't need to be in the body.

In preparation for bundle2, have generatev1() return the raw metadata
and move the header generation to its own function.
Gregory Szorc
streamclone: move payload header line consumption

bundle2 parts have parameters. These are a logical place for "header"
data such as the file count and payload size of stream clone data. In
preparation for supporting stream clones with bundle2, move the
consumption of the header line from the payload into

Note: the header line is still being emitted by generatev1(). This will
be addressed in a subsequent patch.
Gregory Szorc
streamclone: teach canperformstreamclone to be bundle2 aware

We add an argument to canperformstreamclone() to return False if a
bundle2 stream clone is available. This will enable the legacy stream
clone step to no-op when a bundle2 stream clone is supported.

The commented code will be made active when bundle2 supports streaming

This patch does foreshadow the introduction of the "stream" bundle2
capability and its "v1" sub-capability. The bundle2 capability mirrors
the existing "stream" capability and is needed so clients know whether a
server explicitly supports streaming clones over bundle2 (servers up to
this point support bundle2 without streaming clone support).

The sub-capability will denote which data formats and variations are
supported. Currently, the value "v1" denotes the existing streaming
clone data format, which I intend to reuse inside a bundle2 part. My
intent is to eventually introduce alternate data formats that can be
produced and consumed more efficiently. Having a sub-capability means
we don't need to introduce a new top-level bundle2 capability when new
formats are introduced. This doesn't really have any implications
beyond making the capabilities namespace more organized.
Gregory Szorc
streamclone: refactor canperformstreamclone to accept a pullop

This isn't strictly necessary. But a lot of pull functionality accepts a
pulloperation so extra state can be added easily. It also enables
extensions to perform more powerful things.
Gregory Szorc
exchange: expose bundle2 availability on pulloperation

Like the previous patch, the value is cached and will prevent a function
level import in streamclone.py.
Gregory Szorc
exchange: expose bundle2 capabilities on pulloperation

This adds a cache and makes accessing the capabilities slightly simpler,
as you don't need to directly go through the bundle2 module. This will
also help prevent a function-level import in streamclone.py.

This patch arguably isn't necessary. But I think it makes things
slightly nicer.
FUJIWARA Katsunori
keyword: make restrict mode False while updating files for rollback

This is a preparation for using 'repo.rollback()' instead of aborting
a current running transaction for "shelve" and "unshelve".

Before this patch, updating files as a part of 'repo.rollback()'
overridden by keyword extension always follows 'restrict' mode of the
command currently executed.

"merge", "unshelve" and so on should be 'restrict'-ed, because keyword
expansion may cause unexpected conflicts at merging while these

But, if 'repo.rollback()' is invoked while executing 'restrict'-ed
commands, modified files in the working directory are marked as
"CLEAN" unexpectedly by code path below:

        # 'lookup' below is True at updating modified files for rollback
        kwcmd = self.restrict and lookup # kwexpand/kwshrink
                if kwcmd:

On the other hand, "rollback" command isn't 'restrict'-ed, because
rollbacking itself doesn't imply merging.

Therefore, disabling 'restrict' mode while updating files as a part of
'repo.rollback()' regardless of current 'restrict' mode should be