Since os.environ may be overridden in run-tests.py, several important
variables such as PATH weren't restored.
I don't like the idea of using the system hg *by default* because the
executable and the configs are out of our control. But I don't mind as
long as the tests pass.
This patch adds a `phabread` command generating plain-text patches from
Phabricator, suitable for `hg import`. It respects `hg:meta` so user and
date information might be preserved. And it removes `Summary:` field name
which makes the commit message a bit tidier.
To support stacked diffs, a `--stack` flag was added to read dependent
patches recursively.
The `phabsend` command is intended to provide `hg email`-like experience -
sending a stack, setup dependency information and do not amend existing
changesets.
It uses differential.createrawdiff and differential.revision.edit Conduit
API to create or update a Differential Revision.
Local tags like `D123` are written indicating certain changesets were sent
to Phabricator. The `phabsend` command will use obsstore and tags
information to decide whether to update or create Differential Revisions.
The default Phabricator client arcanist is not friendly to send a stack of
changesets. It works better when a feature branch is reviewed as a single
review unit. However, we want multiple revisions per feature branch.
To be able to have an `hg email`-like UX to send and receive a stack of
commits easily, it seems we have to re-invent things. This patch adds
`phabricator.py` speaking Conduit API [1] in `contrib` as the first step.
This may also be an option for people who don't want to run PHP.
Config could be done in `hgrc` (instead of `arcrc` or `arcconfig`):
[phabricator]
# API token. Get it from https://phab.mercurial-scm.org/conduit/login/
token = cli-xxxxxxxxxxxxxxxxxxxxxxxxxxxx
url = https://phab.mercurial-scm.org/
# callsign is used by the next patch
callsign = HG
This patch only adds a single command: `debugcallconduit` to keep the patch
size small. To test it, having the above config, and run:
$ hg debugcallconduit diffusion.repository.search <<EOF
> {"constraints": {"callsigns": ["HG"]}}
> EOF
The result will be printed in prettified JSON format.
[1]: Conduit APIs are listed at https://phab.mercurial-scm.org/conduit/
People often want to know what they are working on *now*. As part of
this, they also commonly want to know how that work is related to other
changesets in the repo so they can perform common actions like rebase,
histedit, and merge.
`hg show work` made headway into this space. However, it is geared
towards a complete repo view as opposed to just the current line of
work. If you have a lot of in-flight work or the repo has many heads,
the output can be overwhelming. The closest thing Mercurial has to
"show me the current thing I'm working on" that doesn't require custom
revsets is `hg qseries`. And this requires MQ, which completely changes
workflows and repository behavior and has horrible performance on large
repos. But as sub-optimal as MQ is, it does some things right, such as
expose a model of the repo that is easy for people to reason about.
This simplicity is why I think a lot of people prefer to use MQ, despite
its shortcomings.
One common development workflow is to author a series of linear
changesets, using bookmarks, branches, anonymous heads, or even topics
(3rd party extension). I'll call this a "stack." You periodically
rewrite history in place (using `hg histedit`) and reparent the stack
against newer changesets (using `hg rebase`). This workflow can be
difficult because there is no obvious way to quickly see the current
"stack" nor its relation to other changesets. Figuring out arguments to
`hg rebase` can be difficult and may require highlighting and pasting
multiple changeset nodes to construct a command.
The goal of this commit is to make stack based workflows simpler
by exposing a view of the current stack and its relationship to
other releant changesets, notably the parent of the base changeset
in the stack and newer heads that the stack could be rebased or merged
into.
Introduced is the `hg show stack` view. Essentially, it finds all
mutable changesets from the working directory revision in both
directions, stopping at a merge or branch point. This limits the
revisions to a DAG linear range.
The stack is rendered as a concise list of changesets. Alongside the
stack is a visualization of the DAG, similar to `hg log -G`.
Newer public heads from the branch point of the stack are rendered
above the stack. The presence of these heads helps people understand
the DAG model and the relationship between the stack and changes made
since the branch point of that stack. If the "rebase" command is
available, a `hg rebase` command is printed for each head so a user
can perform a simple copy and paste to perform a rebase.
This view is alpha quality. There are tons of TODOs documented
inline. But I think it is good enough for a first iteration.
Not only is the output of these commands inconsistent with respect to each
other when a file is deleted, they are internally inconsistent depending upon
whether the deleted file is in the top level repo or a subrepo. It seemed
easier to show the problems, rather than describe them. The original goal was
to fix the summary command with respect to deleted files. I haven't fixed any
of the other issues yet, in case anybody believes the current subrepo behavior
is correct.
I think a natural understanding of clean/dirty is that they are two opposite
values of a single binary repo state. If `hg update --clean -r .` changes a
file, then naturally that repo was dirty, and `hg update --check` should have
blocked it. Deleted files are special, in that they don't block a commit. But
they make the filesystem content not the same as a clean checkout.
The ignore regular expression has been updated to detect
"inconsistent config." If present, we track which configs have
that set and we suppress the conflicting defaults error for those
options.
I also added named groups to the regexp to aid readability.
A comment was added to profiling.py to make a desired inconsistent
value error go away.
The existing default value is now formally declared. It seems like the whole
config should be a list, but this is an adventure for the next changesets.
It isn't needed that storecache is derived from repofilecache.
Changes in this patch allow repofilecache and storecache to do in own
__init__() differently from each other.
This is a fix for my 1c4d8237ba73, which used 'bool(dir)' as
checkambig value for revlog.__init__().
I can't remember why I did so in 1c4d8237ba73, but this is obviously
wrong, because only root indexfile is cached via filecache-ed property
of localrepository.
* Scope of "value" is reduced
* index_baserev() is documented
* Error is no longer redundantly set for -2 return values
* Error values are compared <= -2 instead of == -2 to protect
against odd failure scenarios
External hooks end up launching cmd.exe, which knows nothing about $VAR syntax.
For some reason, I thought that Mercurial would substitute in the value, in
order to paper over the platform difference. But I can't find that in the
documentation, and there's at least one other use of this pattern [1].
[1] https://www.mercurial-scm.org/repo/hg/file/tip/tests/test-histedit-fold.t#l477
I've seen revlog._deltachain() appear in a number of performance
profiles. I suspect there are 2 reasons for this:
1. Delta chain resolution performs many index lookups, thus triggering
population of index tuples. Creating possibly tens of thousands of
PyObject will have overhead.
2. Delta chain resolution is a tight loop.
By moving delta chain resolution to C, we can defer instantiation
of full index entry tuples and make the loop faster courtesy of
not running in Python.
We can measure the impact to delta chain resolution via
`hg perflogrevision` using the mozilla-central repo with a recent
manifest having delta chain length of 33726:
$ hg perfrevlogrevision -m 364895
! full
! wall 0.367585 comb 0.370000 user 0.340000 sys 0.030000 (best of 27)
! wall 0.357581 comb 0.360000 user 0.350000 sys 0.010000 (best of 28)
! deltachain
! wall 0.010644 comb 0.010000 user 0.010000 sys 0.000000 (best of 270)
! wall 0.000292 comb 0.000000 user 0.000000 sys 0.000000 (best of 8729)
$ hg perfrevlogrevision --cache -m 364895
! deltachain
! wall 0.003904 comb 0.000000 user 0.000000 sys 0.000000 (best of 712)
! wall 0.000284 comb 0.000000 user 0.000000 sys 0.000000 (best of 9926)
The first test measures savings from both not instantiating index
entries and moving to C. The second test (which doesn't clear the
index caches) essentially isolates the benefits of moving from Python
to C. It still shows a 13.7x speedup (versus 36.4x). And there are
multiple milliseconds of savings within the critical path for resolving
revision data. I think that justifies the existence of C code.
A more striking example of the benefits of this change can be
demonstrated by timing `hg debugdeltachain -m` for the mozilla-central
repo:
$ time hg debugdeltachain -m > /dev/null
before: 1057.4s
after: 503.3s
PyPy2.7 5.8.0: 220.0s
It's worth noting that the C code isn't as optimal as it could be.
We're still instantiating a new PyObject for every revision. A future
optimization would be to reuse the PyObject on the cached index tuple.
We could potentially also get wins by using a memory array of raw
integers. There is also room for a delta chain cache on revlog
instances. Of course, the best optimization is to implement revlog
reading outside of Python so Python doesn't need to be concerned
about the relatively expensive index entries and operations on them.
Let us start registering the existing option. I'm starting with the 'devel'
section because it is full of useful things that are poorly documented. So
registering these will more than other section.
We were passing it as a revision number in one place and as a context
in another. It worked because the only use was in "repo[dest].rev()",
but it was confusing. By always passing a revision number, we can also
remove that unnecessary lookup.
The function lost its last caller in ae209b610844 (patch: replace
functions in fsbackend to use vfs, 2014-06-05) when the callers
started relying on the opener to do the join.
patchbackend() seems to call it on an arbitrary backend, so it seems
to be part of the API. Since all subclasses do something in their
close() methods, I decided to let this one raise an exception rather
than just pass.
Extensions sometimes wants to add other information in the default log output
format (when no templating is used).
Add an empty function named '_exthook' for easing the extension life.
Extensions will be able to wrap this function and collaborate to display
additional information.
Exthook is called after displaying troubles and just before displaying the
files, extra and description.
Add a new test file to test it and not pollute other test files.
This patch adds special comment handling so one can create obsmarkers in
drawdag comments like "# replace: A -> B -> C", "# prune: X, Y, Z",
"split: P -> M, N" and they are just self-explained.
One hitch is that sometimes fcd is actually an absentfilectx which does not
expose any mutator functions. In order to still use the context functions,
we look up the underlying workingfilectx to perform the write there.
One alternate way would be to put the write functions on the absentfilectx and
have them pass-through. While this makes the callsites cleaner, we would need
to decide what its getter functions would return after this point, since
returning None for `data` (and True for `isabsent()`) might no longer be
correct after a write. I discussed with Sidd about just having the getters
raise RuntimeErrors after a mutator has been called, but we actually call
isabsent() in merge.py after running the internal merge tools.
Yuya pointed out that using mutable value as the default could be problematic.
To work around this we now support callable object as default value. This
allows for creating new mutable objects on demand when needed.
