Before this patch, chgui will override the system method, forwarding every
process execution to the client so sessions and process groups can work as
expected. But the chg client will just use stdout, if ui.fout is not stdout or
if the output is set to be captured to safe._buffers, the client will not
behave correctly.
This can happen especially with code prepending "remote:". For example, bundle2
uses ui.pushbuffer, and sshpeer sets fout to ferr. We may have trouble with
interactive commands in the fout set to ferr case but if it really bites us, we
can always send file descriptors to the client.
This patch adds a check to detect the above situations and fallback to the old
ui.system if so. It will make chg happy with test-bundle2-exchange.t,
test-phases-exchange.t, test-ssh-bundle1.t and test-ssh.t.
9f1a3c7b4a28 introduced support for not having a "global" user cache.
In the rare cases where the environment didn't provide the location of the
current home directory, the usercachepath function could return None.
That functionality has since bitrotten and several code paths did not correctly
check for usercachepath returning None:
$ HOME= XDG_CACHE_HOME= hg up --config extensions.largefiles=
getting changed largefiles
abort: unknown largefiles usercache location
Dropping the partial support for it is thus not really a backward compatibility
breaking change.
Thus: consistently fail early if the usercache location is unknown.
It is relevant to be able to control where the largefiles are stored and how
they propagate, but that should probably be done differently. The dysfunctional
code just gets in the way.
Before this patch shelve never preserved branch information,
so after applying unshelve branch was the same as it was
on working copy no matter in which branch shelve took place.
This patch makes bare shelving(with no files specified, without
interactive,include and exclude option) remembers information if
the working directory was on newly created branch ,in other words
working directory was on different branch than its first parent.
In this situation unshelving restores branch information to the working
directory.
This patch prepares for restoring newly created branch only on
bare shelve later because information about new-branch will be
preserved only when shelve was bare and working copy branch
was different than branch of its parent. In other case information
about new-branch will be gone, so unshelve will not recognise that
shelve was made on new-branch and it will not restore branch
information from the bundle to the working directory.
Replaces invocations os.path functions to methods in vfs. Unfortunately
(in my view) this makes code less readable, because instead of using
clear variable names with path it needs to replace them with vfs(..).
I need guidance how to make such transition look more readable.
For example in this patch there is example with few places with
wvfs.join(standindir), standindir before this patch was absolute
path, in this it is changed to relative because it is used also
in expression wvfs.join(standindir, pat).
chg has its own pager implementation that it wants to skip pager's uisetup.
It is currently done by redirecting stdout to /dev/null, which has unintended
side effects. This patch makes pager aware of chg and skip uisetup directly
from pager. We may want to merge chg and pager's pager implementation to
make this unnecessary in the future.
SocketServer.ForkingMixIn uses os._exit which will skip all cleanup handlers.
We want to run __del__ to make things like transactions, {ssh,http}peer,
atomictempfile, dirstateguard, etc. work.
This patch adds a "gc.collect()" to trigger __del__. It is helpful for chg
to pass some test cases in test-devel-warnings.t.
It's possible for the blackboxui code to do a "del self._bbvfs", then ui.copy()
or similar attempt will fail. It will also fail when constructing a blackboxui
from a non-blackbox ui.
This patch fixes the issue by not assuming any _bb* attr is set.
Closing stdin is unexpected by chgserver and is not a good idea generally.
This patch refactors related code a bit and make sure stdin is not closed.
It will make chg much happier on test-histedit*.t.
The current chgserver design is to use one server to handle multiple repos
which has same [extensions] config. Previously the client uses --cwd / to
avoid creating a repo object. Now we need to set repo to None before we
have code to make "serve" command norepo when it's chg.
Previously, if extensions fail to load, chg server will just keep working
without those extensions. It will print a warning message but only if a new
server starts.
This patch invalidates the server if any extension failed to load, but still
serve the client (hopefully just) once. It will help chg pass some test cases
of test-bad-extension.t.
In some rare cases (next patch), we may want validate to do "unlink" without
forcing the client reconnect. This patch addes a new "reconnect" instruction
and makes "unlink" not to reconnect by default.
Visual C/C++ 9, which Python 2.7 is compatible with, doesn't have C99
support and thus doesn't contain a stdint.h file.
This changeset adds a custom version of stdint.h, created specifically
for Visual C, and uses it when building with that compiler.
We noticed that many users have the intuition of laving the editor empty when
they want to abort the operation. The fact that dropmissing allows user to
delete all edited commits is not intuitive even for users that asked for it.
Let's prevent people from this footgun.
Currently the validate command in chgserver expects config can be loaded
without issues but the config can be broken and chg will print a stacktrace
instead of the parsing error, if a chg server is already running.
This patch adds a handler for ParseError in validate and a new instruction
"exit" to make the client exit without abortmsg. A test is also added to make
sure it will behave as expected.
The chgserver may have a different cwd from the client because of the side
effect of "--cwd" and other possible os.chdir done by extensions. Therefore
relative paths can be misunderstood by the client.
This patch solves it by expanding relative cwd path to absolute one before
sending them via the 'S' channel. It can help chg to pass a testcase in
test-alias.t later.
In 'unix' mode, the server is typically detached from the console. Therefore
a client couldn't see the exception that occurred while instantiating the
server object.
This patch tries to catch the early error and send it to 'e' channel even if
the server isn't instantiated yet. This means the error may be sent before the
initial hello message. So it's up to the client implementation whether to
handle the early error message or error out as protocol violation.
The error handling code is also copied to chgserver.py. I'll factor out them
later if we manage to get chg passes the test suite.
00820e3ad90f (zeroconf: remove camelcase in identifiers, 2016-03-01)
forgot one occurrence of "numAuthorities", which makes test-paths.t
fail for me. I don't even know what zeroconf is, but this patch seems
obviously correct and it fixes the failing test case.
extdiff's uisetup will register new commands. If we do not include it in
confighash, changes to [extdiff] will not get new commands registered.
This patch adds extdiff to confighash and makes it possible for chg to pass
test-extdiff.t.
Using plural form is consistent with other progress units, and "1 out of 5
revisions" sounds more correct. Also, tests don't show this, but if you have
'speed' item in progress.format config, it shows e.g. '100 revisions/sec',
which also seems better.
Before this patch, import-checker reports error below for importing
subversion python binding libraries.
stdlib import "svn.*" follows local import: mercurial
Before this patch, import-checker reports "relative import of stdlib
module" error for importing Pool and SubversionException from svn.core
in subversion.py.
To fix this relative import of stdlib module, this patch adds prefix
'svn.core.' to Pool and SubversionException in source.
These 'svn.core.' relative accessing shouldn't cause performance
impact, because there are much more code paths accessing to
'svn.core.' relative properties.
BTW, in transport.py, this error is avoided by assignment below.
SubversionException = svn.core.SubversionException
But this can't be used in subversion.py case, because:
- such assignment in indented code block causes "don't use camelcase
in identifiers" error of check-code.py
- but it should be placed in indented block, because svn is None at
failure of importing subversion python binding libraries (=
examination of 'svn' is needed)
chgserver now validates and reloads configs automatically. Manually reloading
is no longer necessary. Besides, we are deprecating pid files since the server
will periodically check its ownership of the socket file and exit if it does
not own the socket file any longer, which works more reliable than a pid file.
This patch removes the SIGHUP reload logic from both chg server and client.
Actually since Python 2.3, there is some way to turn top level package into
"namespace package" so that multiple subpackage installed in different part of
the path can still be imported transparently. This feature was previously
thought (at least by myself) to be only provided by some setuptool black magic.
Turning hgext into such namespace package allows third extensions to install
themselves inside the "hgext" namespace package to avoid polluting the global
python module namespace. They will now be able to do so without making it a pain
to use a Mercurial "installed" in a different way/location than these
extensions.
The only constrains is that the extension ship a 'hgext/__init__.py' containing
the same call to 'pkgutil.extend_path' and nothing else. This seems realistic.
The main question that remains is: should we introduce a dedicated namespace for
third party extension (hgext3rd?) to make a clearer distinction between what is
officially supported and what is not? If so, this will be introduced in a follow
up patch.
Keeping the codebase in sync with upstream:
Watchman 4.4 introduced an advanced settling feature that allows publishing
tools to notify subscribing tools of the boundaries for important filesystem
operations.
https://facebook.github.io/watchman/docs/cmd/subscribe.html#advanced-settling
has more information about how this feature works.
This diff connects a signal that we're calling `hg.update` to the mercurial
update function so that mercurial can indirectly notify tools (such as IDEs or
build machinery) when it is changing the working copy. This will allow those
tools to pause their normal actions as the files are changing and defer them
until the end of the operation.
In addition to sending the enter/leave signals for the state, we are able to
publish useful metadata along the same channel. In this case we are passing
the following pieces of information:
1. destination revision hash
2. An estimate of the distance between the current state and the target state
3. A success indicator.
4. Whether it is a partial update
The distance is estimate may be useful to tools that wish to change their
strategy after the update has complete. For example, a large update may be
efficient to deal with by walking some internal state in the subscriber rather
than feeding every individual file notification through its normal (small)
delta mechanism.
We estimate the distance by comparing the repository revision number. In some
cases we cannot come up with a number so we report 0. This is ok; we're
offering this for informational purposes only and don't guarantee its accuracy.
The success indicator is only really meaningful when we generate the
state-leave notification; it indicates the overall success of the update.
Methods _put, _get, _stat were used in remotestore class as
abstract expecting that subclass would implement them. This
commit makes this fact explicit.
Extension to plug into a Watchman daemon, speeding up hg status calls by
relying on OS events to tell us what files have changed.
Originally developed at https://bitbucket.org/facebook/hgwatchman
In preparation for the filesystem monitor extension, include the pywatchman
library. The fbmonitor extension relies on this library to communicate with
the Watchman service. The library is BSD licensed and is taken from
https://github.com/facebook/watchman/tree/master/python.
This package has not been updated to mercurial code standards.
Consider the following use case. User has a set of commits he wants to rebase
onto some destination. Some of the commits in the set are already rebased
and their new versions are now among the ancestors of destination. Traditional
rebase behavior would make the rebase and effectively try to apply older
versions of these commits on top of newer versions, like this:
a` --> b --> a`
(where both 'a`' and 'a``' are rebased versions of 'a')
This is not desired since 'b' might have made changes to 'a`' which can now
result in merge conflicts. We can avoid these merge conflicts since we know
that 'a``' is an older version of 'a`', so we don't even need to put it on top
of 'b'. Rebaseskipobsolete allows us to do exactly that.
Another undesired effect of a pure rebase is that now 'a`' and 'a``' are both
successors to 'a' which is a divergence. We don't want that and not rebasing
'a' the second time allows to avoid it.
This was not enabled by default initially because we wanted to have some more
experience with it. After months of painless usages in multiple places, we are
confident enough to turn it on my default.
When shelve is used by another extension that doesn't
provide all necessary values in opts shelve raises
KeyError exception. This patch fixes this by getting
values from opts dictionary with get method.
This patch consists of changes below (these can't be applied
separately).
- replace revset.extpredicate by registrar.revsetpredicate in
extensions
- remove setup() on an instance named as revsetpredicate in
uisetup()/extsetup() of each extensions
registrar.revsetpredicate doesn't have setup() API.
- put new entry for revsetpredicate into extraloaders in dispatch
This causes implicit loading predicate functions at loading
extension.
This loading mechanism requires that an extension has an instance
named as revsetpredicate, and this is reason why
largefiles/__init__.py is also changed in this patch.
Before this patch, test-revset.t tests that all decorated revset
predicates are loaded by explicit setup() at once ("all or nothing").
Now, test-revset.t tests that any revset predicate isn't loaded at
failure of loading extension, because loading itself is executed by
dispatch and it can't be controlled on extension side.
hgweb_mod.hgweb.repo disappeared in 4d6522c4ac11 (hg: establish
a cache for localrepository instances) and the code for accessing repo
instances from hgweb was later refactored to go through a cache-aware
context manager.
Adapt zeroconf to access the repo instance via the new API.
If an emergency comes in while you're in the middle of an experimental
change, it can be useful to shelve not just files hg already tracks but
also your unknown files while you handle the emergency. This is
especially true if you have hooks intended to prevent you from
forgetting to add new code before you push.
Teach "hg shelve" to optionally shelve unknown files, not just tracked
files. This is functionally similar to --addremove, but with two
differences:
1) Deleted files are not removed.
2) Files added during shelve creation are tracked in extra so that they
can be forgotten by "hg unshelve".
When unshelving, we take care to only forget files if they've been
created during the unshelve operation; if you add a file that's being
tracked in a shelve as an unknown file, it should not become unknown
again when the shelve is unshelved.
92117e4f6f8d improved merging of standin files referencing missing largefiles.
It did however not test or fix commits of such merges; it would abort.
To fix that, change copytostore to skip and warn about missing largefiles
with a message similar the one for failing get from remote filestores. (It
would perhaps in both cases be better to emit a more helpful warning like
"warning: standin file for large1 references 58e24f733a which can't be found in
the local store".)
To test this, make sure commit doesn't find the "missing" largefile in the global
usercache. For further testing, verify that update and status works as expected
after this.
This will also effectively backout 159c82dd6523.
Before the existence of `hg debugbundle --spec`, the process for
defining the BUNDLESPEC value in manifests was not very clear and not
trivial to automate, especially in the case of stream clone bundles.
This patch adds documentation to note the existence of
`hg debugbundle --spec`. We drop the reference to stream clone
requirements handling because it is now redundant with
`hg debugbundle --spec`. While we are here, we further reinforce the
importance of defining BUNDLESPEC.
This extension is copied from
https://bitbucket.org/yuja/chg/ -r 86feb5f2e971
It could be imported as mercurial/chgserver.py, but in that case, we would
have to resolve circular import between chgserver and commandserver. So I
decided to keep it as an extension.
chgserver.chgcmdserver -> commandserver.server
commandserver._servicemap -> chgserver.chgunixservice
Inhibit, one of evolve's extension, would like to change the way rebase works
with obsolete changesets. During a rebase with inhibit, the inhibition of the
obsolescence markers should be lifted for the rebase.
With this small refactoring, inhibit and can wrap the _filterobsoleterevs
function to lift inhibition cleanly and at the same time this change makes
rebases' code more legible.
Before this patch rebase would create divergence when you were rebasing obsolete
changesets on a destination not containing one of its successors.
This patch introduces rebase.allowdivergence to explicitly allow
divergence creation with rebase.
This patch is a refactoring of the code skipping obsolete changesets already
present in destination. It makes the following patches more legible.
Instead of passing all the revs to be rebased to _computeobsoletenotrebased,
we only pass the obsolete revisions of the rebaseset.
The clone bundles feature was introduced in Mercurial 3.6 behind an
experimental and disabled by default flag. The feature has been enabled
on hg.mozilla.org for a few months and has served many terabytes of
clones. Users have been encouraged to use the feature and reception
has been very positive (mainly due to faster clones as a result of
connecting to a CDN). I have heard no feedback about changing the
feature other than inquiries about when it will be enabled by default.
So, I think the feature is ready to be enabled by default.
This patch renames experimental.clonebundles to ui.clonebundles,
documents the option, and enables it by default. References to the
experimental state of clone bundles have been removed. The remaining
config option docs in clonebundles.py have been removed because they
are redudant with `hg help config`.
There are some oddities with behavior of clone bundles. Because clones
with clone bundles are effectively 2 `hg pull` operations, there may be
2 transactions. This could result in hooks running twice. If the
subsequent pull is aborted, it could result in partial rollback and an
incomplete clone. This behavior is a bit wonky and should probably
be documented. If this patch is accepted, I'll send a follow-up to
document it. I don't think this behavior should prevent the feature
being enabled by default. Reworking the clone mechanism to support
interrupted or multi-part clones feels like a major new feature and
something that when implemented can change the hook and rollback
semantics of clone bundles. Besides, partial clone is better than
full rollback and hooks running on initial clone are likely rare, so I
think the impact is minimal.
I screwed up.
When clone bundles is enabled on the server and a compatible client
without the feature enabled clones, the server sends down an
advertisement saying to enable the feature. The server creates the
message which is printed verbatim on the client as an "output" part.
There are 2 problems:
1) The message doesn't respect the client's localization
2) The message contains a reference to the "experimental.clonebundles"
option.
Since clone bundles is about to be marked as non-experimental and the
goal of the advertisement was to encourage clients to test the
experimental feature, let's just remove the broken advertisement since
it no longer serves a purpose.
mercurial_source.getchanges() seems to care about files whose nodeid
has changed even if their contents has not (i.e. it has been
reverted/backed out). The method uses ctx1.status(ctx2) to find
differencing files. However, that method is currently broken and
reports reverted changes as modified. In order to fix that method, we
first need to rewrite getchanges() using manifest.diff(), which does
report reverted files as modified (because it's about differences in
the manifest, so about nodeids).
The next commit will rewrite the way we find changes between two
manifests. By making the cache not care about the difference between
added and modified files, we don't require the rewritten code to care
about that difference either. Also extract the call to ctx.status() to
simplify the next commit.
Previously it wasn't possible to use configuration to avoid
being prompted for e.g. a CC list when using patchbomb to send
emails.
We now make it possible to supply an empty value.
