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

Console View

Legend:   Passed Failed Warnings Failed Again Running Exception Offline No data

Augie Fackler
py3: another passing test

Differential Revision: https://phab.mercurial-scm.org/D6656
Augie Fackler
cleanup: remove redundant import

For some reason the import checker only caught this on py3.

Differential Revision: https://phab.mercurial-scm.org/D6657
Navaneeth Suresh
unshelve: mark unshelve interactive as experimental

This is a follow-up patch to rHG5162753c4c14.
We have the logic for interactive unshelve under `_rebaserestorecommit()`.
So, we might get conflicts even if there are conflicting changes other than
selected changes by the user. We should mark unshelve `--interactive` as
`EXPERIMENTAL` until we solve this issue.

Differential Revision: https://phab.mercurial-scm.org/D6653
Navaneeth Suresh
shelve: modify help text on --interactive

We now have `unshelve --interactive` after rHG5162753c4c14.
So, the help text on `shelve --interactive` suggesting that it
only works for `shelve` can be removed.

Differential Revision: https://phab.mercurial-scm.org/D6654
Taapas Agrawal
continue: added support for graft

This adds support of graft to hg continue plan.

The patch creates a seperate function `cmdutil.continuegraft`
so that continue logic for graft can be called independently.
This logic is registered to the statedetection API as `continuefunc`.

Results are shown as tests.

Differential Revision: https://phab.mercurial-scm.org/D6655
Valentin Gatien-Baron
blackbox: disable extremely verbose logging (issue6110)

This is maybe not the best way to go about fixing this, but anything
is better than the status quo.

Differential Revision: https://phab.mercurial-scm.org/D6611
Valentin Gatien-Baron
convert: add a config option to help doing identity hg->hg conversion

I want to change the computation of the list of files modified by a
commit. In principle, this would simply change a cache. But since this
information is stored in commits rather than a cache, changing it
means changing commit hashes (going forward).

Some users rely on the convert extension from hg to hg not changing
hashes when nothing changes (usually). Allow these users to preserve
hashes despite changes to the changelog files computation by reusing
these files lists when the manifest is unchanged (since these files
list are derived from the manifest).

Differential Revision: https://phab.mercurial-scm.org/D6643
Taapas Agrawal
continue: added support for unshelve

This patch adds the support for `ushelve` in `hg continue` plan.

`hgcontinueunshelve()` has been created for independent calls.
In case an interrupted unshelve is resumed via hg continue the
shelvedstate needs to be loaded seperately. This has been
ensured by `_loadunshelvedstate()`

`hgcontinueunshelve()` is then registered as `continuefunc` for state
detection API.

Results are shown as tests.

Differential Revision: https://phab.mercurial-scm.org/D6652
Navaneeth Suresh
unshelve: add interactive mode

Until now, there is no way to `unshelve` selected changes only from
the stored shelve as given in issue6162. This patch makes `unshelve`
perform with certain changes only by adding an interactive mode.

Differential Revision: https://phab.mercurial-scm.org/D6596
Valentin Gatien-Baron
commit: improve the files field of changelog for merges

Currently, the files list of merge commits repeats all the deletions
(either actual deletions, or files that got renamed) that happened
between base and p2 of the merge. If p2 is the main branch, the list
can easily be much bigger than the change being merged.

This results in various problems worth improving:
- changelog is bigger than necessary
- `hg log directory` lists many unrelated merge commits, and `hg log
  -v -r commit` frequently fills multiple screens worth of files
- it possibly slows down adjustlinkrev, by forcing it to read more
  manifests, and that function can certainly be a bottleneck
- the server side of pulls can waste a lot of time simply opening the
  filelogs for pointless files (the constant factors for opening even
  a tiny filelog is apparently pretty bad)

So stop listing such files as described in the code.  Impacted merge
commits and their descendants get a different hash than they would
have without this. This doesn't seem problematic, except for
convert. The previous commit helped with that in the hg->hg case (but
if you do svn->hg twice from scratch, hashes can still change).

The rest of the description is numbers. I don't have much to report,
because recreating the files list of existing repositories is not
easy:
- debugupgradeformat and bundle/unbundle don't recreate the list
- export/import tends to choke quickly applying patches or on
  description that contain diffs,
- merge commits from the convert extension don't have the right files
  list for reasons orthogonal to the current commit
- replaying the merge with hg update/hg merge/hg revert --all/hg
  commit can end up failing in hg revert
- I wasn't sure that using debugsetparents + debugrebuilddirstate
  would really build the right thing

I measured commit time before and after this change, in a case with no
files filtered out, several files filtered out (no difference) and 5k
files filtered out (+1% time).

Recreating the 100 more recent merges in a private repo, the
concatenated uncompressed files lists goes from 1.12MB to
0.52MB. Excluding 3 merges that are not representative, then the size
goes from 570k to 15k.
I converted part of mozilla-central, and observed file list shrinking
quite a bit too, starting at the very first merge, 733641d9feaf, going
from 550 files to 10 files (although they have relatively few merges,
so they probably wouldn't care).

Differential Revision: https://phab.mercurial-scm.org/D6613
Taapas Agrawal
continue: added logic for hg continue

This is part of GSoC19 project `Implement abort and
continue commands`. This patch is part of the continue plan.

This adds the basic logic for hg continue. This command
aborts an multistep operation like graft, histedit, rebase,
transplant and unshelve if they are in an unfinished state.

The first part of the logic is determining the unfinished
operation from the state detection API under statemod.
This API is extended to support hg continue by adding a method
to register the abort logic as a function (here continuefunc).

Once the unfinished operation is determined the registered
logic is used to resume the command in case it is interrupted.
The benefit of this kind of framework is that any new extension
developed can support hg continue by registering the command
and logic under statedetection API.

hg continue currently supports --dry-run/-n flag only.
It is used to dry run hg abort

Differential Revision: https://phab.mercurial-scm.org/D6645
Ian Moody
phabricator: demonstrate broken phabread on string local:commit times

Differential Revision: https://phab.mercurial-scm.org/D6649
Taapas Agrawal
continue: added support for rebase

This adds support of rebase to hg continue plan.

An independent continue logic for rebase is created
under continuerebase() function. For this a seperate
rebaseruntime object is created under the function to
handle an interrupted rebasestate.

Results of tests are shown.

Differential Revision: https://phab.mercurial-scm.org/D6646
Ian Moody
phabricator: handle local:commits time being string or int

When setting local:commits arcanist has different behaviour depending on
whether the repo is git or hg. With hg it sets the time as a number, since it
calls PHP's strtotime on the value, but with git it sets it as a string.
Normally this wouldn't be an issue since phabread wouldn't be interacting with
Phabricator Revisions for git repos, but Mozilla has a secondary workflow for
git users that uses the git-cinnabar tool to interact with their hg repos. When
a git-cinnabar user uses the moz-phab tool to submit patches for mozilla-central
it makes use of Mozilla's fork of arcanist, which works with their local git
version of m-c, and thus sets the local:commit time as a string, and then
translates the commit hashes.

Currently when encountering such DREVS phabread dies with "TypeError: %d format:
a number is required, not str".

phabsend also used to set it as a string but wouldn't have encountered the
issue with its own DREVs since it would read hg:meta first.

Differential Revision: https://phab.mercurial-scm.org/D6650
Valentin Gatien-Baron
tests: show the files fields of changelogs for many merges

I don't think there's coverage for many of the subtle cases, and I
found it hard to understand what the code is doing by reading it.  The
test takes 40s to run on a laptop, or 9s with --chg.

I have yet to find a description of what the files field is supposed
to be for merges. I thought it could be one of:
1. the files added/modified/removed relative to p1 (wouldn't seem
  useful, but `hg diff -c -r mergerev` has this behavior)
2. the files with filelog nodes not in either parent (i.e., what is
needed to create a bundle out of a commit)
3. the files added/removed/modified files by merge itself [1]

It's clearly not 1, because file contents merges are symmetric. It's
clearly not 2 because removed files and exec bit changes are
listed. It's also not 3 but I think it's intended to be 3 and the
differences are bugs.

Assuming 3, the test shows that, for merges, the list of files both
overapproximates and underapproximates. All the cases involve file
changes not in the filelog but in the manifest (existence of file
at revision, exec bit and file vs symlink).

I didn't look at all underapproximations, but they looked minor. The
two overapproximations are problematic though because they both cause
potentially long lists of files when merging cleanly.


[1] even what it means for the merge commit itself to change a file is
not completely trivial. A file in the merge being the same as in one
of the parent is too lax as it would consider that merges change
nothing when they revert all the changes done on one side. The
criteria used in the test and in the next commit for "merge didn't
touch a file" is:
- the parents and the merge all have the same file
- or, one parent didn't touch the file and the other parent contains
  the same file as the merge

Differential Revision: https://phab.mercurial-scm.org/D6612
Raphaël Gomès
rust-utils: add docstrings and doctests for utils.rs

Differential Revision: https://phab.mercurial-scm.org/D6635
Raphaël Gomès
rust: switch hg-core and hg-cpython to rust 2018 edition

Many interesting changes have happened in Rust since the Oxidation Plan was
introduced, like the 2018 edition and procedural macros:

    - Opting in to the 2018 edition is a clear benefit in terms of future
      proofing, new (nice to have) syntactical sugar notwithstanding. It
      also has a new non-lexical, non-AST based borrow checker that has
      fewer bugs(!) and allows us to write correct code that in some cases
      would have been rejected by the old one.
    - Procedural macros allow us to use the PyO3 crate which maintainers have
      expressed the clear goal of compiling on stable, which would help in
      code maintainability compared to rust-cpython.

In this patch are the following changes:
    - Removing most `extern crate` uses
    - Updating `use` clauses (`crate` keyword, nested `use`)
    - Removing `mod.rs` in favor of an aptly named module file

Like discussed in the mailing list (
https://www.mercurial-scm.org/pipermail/mercurial-devel/2019-July/132316.html
), until Rust integration in Mercurial is considered to be out of the
experimental phase, the maximum version of Rust allowed is whatever the latest
version Debian packages.

Differential Revision: https://phab.mercurial-scm.org/D6597
Raphaël Gomès
rust-utils: remove buggy assertion

While this assertion had good intentions, it broke existing behavior with a
nasty panic.

Differential Revision: https://phab.mercurial-scm.org/D6651
Valentin Gatien-Baron
commit: improve the files field of changelog for merges

Currently, the files list of merge commits repeats all the deletions
(either actual deletions, or files that got renamed) that happened
between base and p2 of the merge. If p2 is the main branch, the list
can easily be much bigger than the change being merged.

This results in various problems worth improving:
- changelog is bigger than necessary
- `hg log directory` lists many unrelated merge commits, and `hg log
  -v -r commit` frequently fills multiple screens worth of files
- it possibly slows down adjustlinkrev, by forcing it to read more
  manifests, and that function can certainly be a bottleneck
- the server side of pulls can waste a lot of time simply opening the
  filelogs for pointless files (the constant factors for opening even
  a tiny filelog is apparently pretty bad)

So stop listing such files as described in the code.  Impacted merge
commits and their descendants get a different hash than they would
have without this. This doesn't seem problematic, except for
convert. The previous commit helped with that in the hg->hg case (but
if you do svn->hg twice from scratch, hashes can still change).

The rest of the description is numbers. I don't have much to report,
because recreating the files list of existing repositories is not
easy:
- debugupgradeformat and bundle/unbundle don't recreate the list
- export/import tends to choke quickly applying patches or on
  description that contain diffs,
- merge commits from the convert extension don't have the right files
  list for reasons orthogonal to the current commit
- replaying the merge with hg update/hg merge/hg revert --all/hg
  commit can end up failing in hg revert
- I wasn't sure that using debugsetparents + debugrebuilddirstate
  would really build the right thing

I measured commit time before and after this change, in a case with no
files filtered out, several files filtered out (no difference) and 5k
files filtered out (+1% time).

Recreating the 100 more recent merges in a private repo, the
concatenated uncompressed files lists goes from 1.12MB to
0.52MB. Excluding 3 merges that are not representative, then the size
goes from 570k to 15k.
I converted part of mozilla-central, and observed file list shrinking
quite a bit too, starting at the very first merge, 733641d9feaf, going
from 550 files to 10 files (although they have relatively few merges,
so they probably wouldn't care).

Differential Revision: https://phab.mercurial-scm.org/D6613
Valentin Gatien-Baron
tests: show the files fields of changelogs for many merges

I don't think there's coverage for many of the subtle cases, and I
found it hard to understand what the code is doing by reading it.  The
test takes 40s to run on a laptop, or 9s with --chg.

I have yet to find a description of what the files field is supposed
to be for merges. I thought it could be one of:
1. the files added/modified/removed relative to p1 (wouldn't seem
  useful, but `hg diff -c -r mergerev` has this behavior)
2. the files with filelog nodes not in either parent (i.e., what is
needed to create a bundle out of a commit)
3. the files added/removed/modified files by merge itself [1]

It's clearly not 1, because file contents merges are symmetric. It's
clearly not 2 because removed files and exec bit changes are
listed. It's also not 3 but I think it's intended to be 3 and the
differences are bugs.

Assuming 3, the test shows that, for merges, the list of files both
overapproximates and underapproximates. All the cases involve file
changes not in the filelog but in the manifest (existence of file
at revision, exec bit and file vs symlink).

I didn't look at all underapproximations, but they looked minor. The
two overapproximations are problematic though because they both cause
potentially long lists of files when merging cleanly.


[1] even what it means for the merge commit itself to change a file is
not completely trivial. A file in the merge being the same as in one
of the parent is too lax as it would consider that merges change
nothing when they revert all the changes done on one side. The
criteria used in the test and in the next commit for "merge didn't
touch a file" is:
- the parents and the merge all have the same file
- or, one parent didn't touch the file and the other parent contains
  the same file as the merge

Differential Revision: https://phab.mercurial-scm.org/D6612
Valentin Gatien-Baron
convert: add a config option to help doing identity hg->hg conversion

I want to change the computation of the list of files modified by a
commit. In principle, this would simply change a cache. But since this
information is stored in commits rather than a cache, changing it
means changing commit hashes (going forward).

Some users rely on the convert extension from hg to hg not changing
hashes when nothing changes (usually). Allow these users to preserve
hashes despite changes to the changelog files computation by reusing
these files lists when the manifest is unchanged (since these files
list are derived from the manifest).

Differential Revision: https://phab.mercurial-scm.org/D6643
Valentin Gatien-Baron
blackbox: disable extremely verbose logging (issue6110)

This is maybe not the best way to go about fixing this, but anything
is better than the status quo.

Differential Revision: https://phab.mercurial-scm.org/D6611
Ian Moody
phabricator: demonstrate broken phabread on string local:commit times

Differential Revision: https://phab.mercurial-scm.org/D6649
Taapas Agrawal
continue: added support for unshelve

This patch adds the support for `ushelve` in `hg continue` plan.

`hgcontinueunshelve()` has been created for independent calls.
In case an interrupted unshelve is resumed via hg continue the
shelvedstate needs to be loaded seperately. This has been
ensured by `_loadunshelvedstate()`

`hgcontinueunshelve()` is then registered as `continuefunc` for state
detection API.

Results are shown as tests.

Differential Revision: https://phab.mercurial-scm.org/D6652
Navaneeth Suresh
unshelve: add interactive mode

Until now, there is no way to `unshelve` selected changes only from
the stored shelve as given in issue6162. This patch makes `unshelve`
perform with certain changes only by adding an interactive mode.

Differential Revision: https://phab.mercurial-scm.org/D6596
Taapas Agrawal
continue: added support for rebase

This adds support of rebase to hg continue plan.

An independent continue logic for rebase is created
under continuerebase() function. For this a seperate
rebaseruntime object is created under the function to
handle an interrupted rebasestate.

Results of tests are shown.

Differential Revision: https://phab.mercurial-scm.org/D6646
Taapas Agrawal
continue: added logic for hg continue

This is part of GSoC19 project `Implement abort and
continue commands`. This patch is part of the continue plan.

This adds the basic logic for hg continue. This command
aborts an multistep operation like graft, histedit, rebase,
transplant and unshelve if they are in an unfinished state.

The first part of the logic is determining the unfinished
operation from the state detection API under statemod.
This API is extended to support hg continue by adding a method
to register the abort logic as a function (here continuefunc).

Once the unfinished operation is determined the registered
logic is used to resume the command in case it is interrupted.
The benefit of this kind of framework is that any new extension
developed can support hg continue by registering the command
and logic under statedetection API.

hg continue currently supports --dry-run/-n flag only.
It is used to dry run hg abort

Differential Revision: https://phab.mercurial-scm.org/D6645
Raphaël Gomès
rust-utils: remove buggy assertion

While this assertion had good intentions, it broke existing behavior with a
nasty panic.

Differential Revision: https://phab.mercurial-scm.org/D6651
Ian Moody
phabricator: handle local:commits time being string or int

When setting local:commits arcanist has different behaviour depending on
whether the repo is git or hg. With hg it sets the time as a number, since it
calls PHP's strtotime on the value, but with git it sets it as a string.
Normally this wouldn't be an issue since phabread wouldn't be interacting with
Phabricator Revisions for git repos, but Mozilla has a secondary workflow for
git users that uses the git-cinnabar tool to interact with their hg repos. When
a git-cinnabar user uses the moz-phab tool to submit patches for mozilla-central
it makes use of Mozilla's fork of arcanist, which works with their local git
version of m-c, and thus sets the local:commit time as a string, and then
translates the commit hashes.

Currently when encountering such DREVS phabread dies with "TypeError: %d format:
a number is required, not str".

phabsend also used to set it as a string but wouldn't have encountered the
issue with its own DREVs since it would read hg:meta first.

Differential Revision: https://phab.mercurial-scm.org/D6650
Raphaël Gomès
rust-utils: use new find_dirs iterator

In cad3dde7a573, the `find_dirs` util was introduced, but the second changeset
that made use of it didn't apply. This change fixes the issue.

Differential Revision: https://phab.mercurial-scm.org/D6639
Raphaël Gomès
rust-2018: switch hg-core and hg-cpython to rust 2018 edition

Many interesting changes have happened in Rust since the Oxidation Plan was
introduced, like the 2018 edition and procedural macros:

    - Opting in to the 2018 edition is a clear benefit in terms of future
      proofing, new (nice to have) syntactical sugar notwithstanding. It
      also has a new non-lexical, non-AST based borrow checker that has
      fewer bugs(!) and allows us to write correct code that in some cases
      would have been rejected by the old one.
    - Procedural macros allow us to use the PyO3 crate which maintainers have
      expressed the clear goal of compiling on stable, which would help in
      code maintainability compared to rust-cpython.

In this patch are the following changes:
    - Removing most `extern crate` uses
    - Updating `use` clauses (`crate` keyword, nested `use`)
    - Removing `mod.rs` in favor of an aptly named module file

Like discussed in the mailing list (
https://www.mercurial-scm.org/pipermail/mercurial-devel/2019-July/132316.html
), until Rust integration in Mercurial is considered to be out of the
experimental phase, the maximum version of Rust allowed is whatever the latest
version Debian packages.

Differential Revision: https://phab.mercurial-scm.org/D6597
Raphaël Gomès
rust-utils: add docstrings and doctests for utils.rs

Differential Revision: https://phab.mercurial-scm.org/D6635
Martin von Zweigbergk
copies: remove unnecessary override of p[12]copies() in workingctx

The implementation is identical to the version inherited from basectx.

Differential Revision: https://phab.mercurial-scm.org/D6647
Matt Harbison
inno: correct the path display in a literal block of the readme

Otherwise, the path components allrantogether.

Differential Revision: https://phab.mercurial-scm.org/D6648
Martin von Zweigbergk
py3: source-transform only call-sites of iteritems(), not definitions

branchmap.branchcache, among other classes, defines a
iteritems(). That currently gets replaced by items() by the source
transformer. That makes it harder for extensions to work with both py2
and py3, since they have to call either items() or iteritems() on
branchcache. Let's not replace definitions of iteritems() (and
itervalues()) and only replace the call-sites. We need to also add an
items() alias to branchcache (etc) so our transformer call-sites will
find it.

Differential Revision: https://phab.mercurial-scm.org/D6641
Taapas Agrawal
abort: removed labels argument from abortmerge()

Labels are used to label the code that belongs to `working copy` and `merge rev`
in case of a conflicted state.
No such labelling is required while aborting merge as conflicted parts
are reverted to normal.

Differential Revision: https://phab.mercurial-scm.org/D6638
Matt Harbison
tests: properly position conditional output on Windows in test-subrepo.t

The test runner doesn't always guess the right location when optional output is
missing.  This goes with f6540aba8e3e.

Differential Revision: https://phab.mercurial-scm.org/D6640
Matt Harbison
tests: properly position conditional output on Windows in test-subrepo.t

The test runner doesn't always guess the right location when optional output is
missing.  This goes with f6540aba8e3e.

Differential Revision: https://phab.mercurial-scm.org/D6640
Martin von Zweigbergk
py3: fix formatting of branchmap log messages with repo.filtername=None

`"%s" % None` does not work on py3. I've extracted a little function
for producing a formatted message given the filter name.

Differential Revision: https://phab.mercurial-scm.org/D6644
Martin von Zweigbergk
py3: source-transform only call-sites of iteritems(), not definitions

branchmap.branchcache, among other classes, defines a
iteritems(). That currently gets replaced by items() by the source
transformer. That makes it harder for extensions to work with both py2
and py3, since they have to call either items() or iteritems() on
branchcache. Let's not replace definitions of iteritems() (and
itervalues()) and only replace the call-sites. We need to also add an
items() alias to branchcache (etc) so our transformer call-sites will
find it.

Differential Revision: https://phab.mercurial-scm.org/D6641