The [alias] config section affects a global state: commands.table. It's hard
to trace whether an alias is added by a config option or an extension, and
add/remove aliases in a safe way per chg request. It will hurt performance a
bit if we clean the table and parse aliases every time. Therefore let's just
add it to confighash.
This will make chg pass test-pager.t.
Since we expand environment variables in alias lazily, the _clearenvaliases
hack is no longer necessary.
This resolves an issue that a non-shell alias which has environment variables
in its arguments and is set to use pager will not use pager running with chg.
The 'jlock' code meant to check for a held lock, but it actually just checking for a
lock object. With CPython, this worked because the 'jlock' object is not
referenced outside the '_write' function so reference counting would garbage
collect it and the '_lockref' would return None. With pypy, the garbage
collection would happen at an undefined time and the '_lockref' can still point
to a 'jlock' object outside of '_write'.
The right thing to do here is not only to check for a lock object but also to
check if the lock is held. We update the code to do so and reuse a utility
method that exist on 'localrepo' to help readability. This fix journal related
tests with pypy.
I always read the name "checkcase(path)" as "do we need to check for
case folding at this path", but it's actually (I think) meant to be
read "check if the file system cares about case at this path". I'm
clearly not the only one confused by this as the dirstate has this
property:
def _checkcase(self):
return not util.checkcase(self._join('.hg'))
Maybe we should even inverse the function and call it fscasefolding()
since that's what all callers care about?
All actions but one actually have the same constraints when it comes to validate
the 'action.node' value. So we actually just add this code to a method that can
be overwritten in the one action where it matters.
The now unused 'contraints' related enum and class attribute will be cleaned up
in the next changeset.
Action has a method dedicated to verifying its validity. So we move code
related to constrains into that method. This requires a bit more context to the
'verify' method in the same fashion we were passing the 'prev' argument.
This is an extra step before we can simplify the constraint handling code
further.
It does not seem useful to convert to hex: it is an extra step and they are
longer strings. So we stick to node for the logic. We only convert to short hex
for error when needed. As a nice side effect this remove the explicit constant
usage in'[12:]'. This will also help moving the code around later as we just
have to access action.node.
An upcoming changeset will make the line where this variable is used
slightly too long. Other later changesets will clean that up further and makes
the variable unnecessary, so this is only temporary and it does seems useful to
put anything more complicate in place.
There does not seem to be a reason for this to be a method. So we initialise
the class attribute once and for all at creation time and drop the instance
method.
That method is just returning self.node and is never overridden. We just use
the attribute directly instead and get rid of the method.
This is the beginning of series to simplify and unify verification of constraints
for actions.
The 'journal' naming is already used by the transaction journal. Having an
unrelated group of file with such a close naming is confusing and error prone.
We rename the file used by the 'journal' extension to use 'namejournal' as the
extension track the location of various 'names'.
I've caught multiple extensions in the wild lying about being
'internal', so it's time to move the goalposts on people. Goalpost
moving will continue until third party extensions stop trying to
defeat the system.
With future obs-based shelve, finishing shelve will be different
from just aborting a transaction and I would like to keep both
variants of this functionality in a separate function.
Currently, this code does not have any branching, it just bundles
a commit and saves a patch file. Later, obsolescence-based shelve
will be added, so this code will also create some obsmarkers and
will be one of the few places where obsshelve will be different
from traditional shelve.
This has nothing to do with the future obsshelve implementation, I just
thought that moving this messaging to a separate function will improve
shelve code readability.
Special commitfuncs are created as closures at least twice in shelve's
code and one time special commitfunc is used within another closure.
They all serve very specific purposes like temporarily tweak some
configuration or enable editor, etc. This is not immediately important
to someone reading shelve code, so I think moving this logic to a separate
function is a good idea.
There's no value in it being a closure and everyone who tries to read
the outer function code will be distracted by it. IMO moving it out
significantly improves readability, especially given how clear it is
what mutableancestors function does from its name.
This and a couple of following patches are a preparation to
implementing obsolescense-enabled shelve which was discussed
on a Sprint. If this refactoring is not done, shelve is going
to look even more hackish than now.
This particular commit introduces a slight behavior change. Previously,
if only .hg/shelve/name.patch file exists, but .hg/name.hg does not,
'hg shelve -d name' would fail saying "shelve not found". Now deletion
will only fail if .patch file does not exist (since .patch is used
as an indicator of an existing shelve). Other shelve files being absent
are skipped silently to accommodate for future introduction of obs-based
shelve, which will mean that for some shelves .hg and .patch files exist,
while for others .hg and .oshelve.
Now that all the functionality has been moved to manifestlog/manifestrevlog/etc,
we can finally change all the uses of repo.manifest to use the new versions. A
future diff will then delete repo.manifest.
One additional change in this commit is to change repo.manifestlog to be a
@storecache property instead of @property. This is required by some uses of
repo.manifest require that it be settable (contrib/perf.py and the static http
server). We can't do this in a prior change because we can't use @storecache on
this until repo.manifest is no longer used anywhere.
The 'hg debugcolor' command gains a '--style' flag to display all the configured
labels and their styles. This have many benefits:
* discovering documented label,
* checking consistency between label's style,
* showing the actual style of a label.
The previous ordering were provided by the set. The new output is more stable
and rational. In addition we have some logic to keep the '_background' version
together to help readability.
We are about to introduce a second mode for 'hg debugcolor' that would list the
known label and their configuration, so we split the code related to color and
effect out of the main function.
Before this change, running 'debugcolor' would destroy all color style for the
rest of the process life. We now properly backup and restore the variable
content. Using a global variable is sketchy in general and could probably be
removed. However, this is a quest for another adventure.
When there are unresolved merge conflicts, there is no reason
to make the user wait for rebase to process all of the
already rebased commits just to complain that it cannot do
anything. Abort early.
Windows command lines use double quotes to quote arguments with spaces.
This change is in a series to unify around using single quotes around
commands, and double quotes around interior arguments.
This changeset is taken on stable for consistency with similar update done
before the freeze.
See dc90bb772edc, 675a0be03493, 518b94d8f911 and 149a699cfd98.
Windows command lines use double quotes to quote arguments with spaces.
This change is in a series to unify around using single quotes around
commands, and double quotes around interior arguments.
This patch makes sure that either "tmpl" or "mapfile" is exclusively set,
which is the same behavior as common log-like templates and formatter outputs.
See the previous patch for why.
This prepares for the API change to support template aliases. I'm going to
extract a factory function of templater that reads a map file:
# original
templater(mapfile, ..., cache, ...)
# new
templater.frommapfile(mapfile, ...) # read mapfile to build cache/map
templater(..., cache, ...) # use specified cache (= map elements)
This will make it clear to isolate stock styles (i.e. map files) from user
aliases. Template aliases should be applied to command arguments and templates
in hgrc, but not to map files. Otherwise, our stock styles and web templates
could be modified unintentionally.
This patch makes sure that either "tmpl" or "mapfile" is exclusively set. It's
theoretically a behavior change, since you could put new keywords in template
by defining them in a map file before:
# mapfile
foo = "{rev}"
# hgrc
[bugzilla]
style = mapfile
template = {foo}
But the old behavior would be a bug because bugzilla.template is documented
as "overrides style if specified". Also, common log-like templates and
formatter doesn't allow using mapfile-keywords in a separate template. So
I decided to make a BC.
Since there was no test for the bugzilla extension, this adds new test that
covers style/template output.
This extension lets you direct specific ui.log() information to shell
commands, spawned in the background. This can be used to, say, capture
timings, commandfailure tracebacks, etc., making the output available
to other command-line tools.
Before, when converting revisions without also including their already
converted parents in convert.hg.revs, the parents would no longer be parents.
That seems unfortunate and we dare to assume that nobody ever wants that.
Instead, preserve parents that are outside the current convert range but
already have been converted.
The parents returned in getcommit() are unconditionally converted, so we
introduce a separate optparents with optional parents.
The default of pushing all largefiles referenced in outgoing revisions is safe,
but also expensive and sometimes not what is needed. We thus introduce a
--lfrev option, similar to what pull already has.
By specifying an empty set of revisions (or null), it is possible to get lazy
(and insecure!) pushes of revisions without referenced largefiles, similar to
how pull works.
prepushoutgoinghook was introduced in 8dfcd476a7f7 and largefiles is the only
in-tree use of it. Refactor it to be more useful for other use cases in
largefiles.
Before this patch, extensions expecting a different random state per command
will break since the chg request handler will inherit a same random state
from the parent daemon process.
This patch addresses the issue by calling random.seed() after fork.
Before this patch, if the server address is long, the server will fail to
listen and throw the error:
socket.error: AF_UNIX path too long
It is because AF_UNIX path usually has a very short length limit (107 chars on
common platforms, see sys/un.h).
This patch addresses the issue by using relative path instead. Therefore the
directory length does not matter. It helps run tests with chg using a long
$TMPDIR.
A previous patch moved it to an incorrect place. Since dispatch._earlygetopt
has side effects on args, we need to move it to the place before _earlygetopt.
This commit is part of bigger effort described in 'Windows UTF-8' plan.
It is not changing all invocations but the ones where change is
obviously correct and doesn't require complicated changes.
Before this patch, rebase --continue would crash when trying to resume a rebase
of obsolete revisions whose successors were in the destination.
This patch adds logic to recompute the mapping when rebase is resumed. This
patch also adds a test that showcased the crash before the code change.
This patch extracts the error handling code path to go in a separate function.
In the next patch we will able to reuse this logic and avoid duplicated code.
writebundle() writes a bundle2 bundle or a plain changegroup1. Imagine
away the "2" in "bundle2.py" for a moment and this change should makes
sense. The bundle wraps the changegroup, so it makes sense that it
knows about it. Another sign that this is correct is that the delayed
import of bundle2 in changegroup goes away.
I'll leave it for another time to remove the "2" in "bundle2.py"
(alternatively, extract a new bundle.py from it).
When code like filemerge._iprompt calls ui.prompt, it expects
the user to see the output in addition to getting the prompt.
Other code such as histedit may call ui.pushbuffer, but its
goal is not to interfere with prompts, so this commit adds
an optional prompt flag to ui.write and has _readline
include that argument.
ui.promptchoice calls ui.prompt which calls ui._readline.
This commit also updates hgext.color.write.
SyntaxError is the class representing syntax errors in Python code. We should
use a dedicated exception class for our needs. With this change, unnecessary
re-wrapping of SyntaxError can be eliminated.
Super long first line in description lead to very long file name that
windows is unhappy about. We restrict the name to 75 char to avoid the
issue.
75 seems fine and leave some extra room for '__#' suffix in case of conflict.
I does not seems worthwhile to add a dedicated config option to configure the
length. It can be done in the future if there is an actual user demand for it.
Before this patch, deprecated options below are used in synopsis of
command help, even though they aren't listed up as available options
by default. These might confuse readers.
- -n (no-op, now) of strip
- -a/--active of branches
- -f/--force of merge
cf6cc5344afa added 'ignoresub' argument to ui.configitems(), but zeroconf
wrapper wasn't updated. It caused the following crash:
Traceback (most recent call last):
File "bin/hg", line 43, in <module>
mercurial.dispatch.run()
File "lib/python/mercurial/dispatch.py", line 54, in run
sys.exit((dispatch(request(sys.argv[1:])) or 0) & 255)
File "lib/python/mercurial/dispatch.py", line 120, in dispatch
ret = _runcatch(req)
File "lib/python/mercurial/dispatch.py", line 191, in _runcatch
return _dispatch(req)
File "lib/python/mercurial/dispatch.py", line 924, in _dispatch
cmdpats, cmdoptions)
File "lib/python/mercurial/dispatch.py", line 681, in runcommand
ret = _runcommand(ui, options, cmd, d)
File "lib/python/mercurial/extensions.py", line 195, in closure
return func(*(args + a), **kw)
File "lib/python/hgext/zeroconf/__init__.py", line 180, in cleanupafterdispatch
return orig(ui, options, cmd, cmdfunc)
File "lib/python/mercurial/dispatch.py", line 1055, in _runcommand
return checkargs()
File "lib/python/mercurial/dispatch.py", line 1015, in checkargs
return cmdfunc()
File "lib/python/mercurial/dispatch.py", line 921, in <lambda>
d = lambda: util.checksignature(func)(ui, *args, **cmdoptions)
File "lib/python/mercurial/util.py", line 991, in check
return func(*args, **kwargs)
File "lib/python/mercurial/commands.py", line 5405, in paths
pathitems = sorted(ui.paths.iteritems())
File "lib/python/mercurial/util.py", line 723, in __get__
result = self.func(obj)
File "lib/python/mercurial/ui.py", line 619, in paths
return paths(self)
File "lib/python/mercurial/ui.py", line 1099, in __init__
for name, loc in ui.configitems('paths', ignoresub=True):
File "lib/python/mercurial/extensions.py", line 195, in closure
return func(*(args + a), **kw)
TypeError: configitems() got an unexpected keyword argument 'ignoresub'
We have no test coverage for zeroconf, so I've added a minimal test that
could reproduce this problem.
Rather than look for the lowest revision, see if the rebase state is tracking
the parents of this revision. Otherwise we can't handle multiple revisions in
one rebase that includes a merge revision.
Fixes issue5044.
This patch fixes problems below:
- ":hg:" role should be followed by not '"' but '`'
- there is a help topic not "default-push" but "config.default-push"
Previously, if the largefile was deleted at the time of a commit, the standin
was silently not updated and its current state (possibly garbage) was recorded.
The test makes it look like this is somewhat of an edge case, but the same thing
happens when an `hg revert` followed by `rm` changes the standin.
Aside from the second invocation of this in lfutil.updatestandinsbymatch()
(which is what triggers this test case), the three other uses are guarded by
dirstate checks for added or modified, or an existence check in the filesystem.
So aborting in lfutil.updatestandins() should be safe, and will avoid silent
skips in the future if this is used elsewhere.
The change in 6fce9a02f069 to handle a normal -> largefile switch was too
aggressive in preserving the original matcher names. If a largefile is
explicitly provided by the user, but only the standin exists in dirstate, then
only the standin can be committed.
There's still maybe an issue when the largefile is deleted outside of Mercurial:
$ rm large
$ hg ci -m "oops" large
large: The system cannot find the file specified
nothing changed
[1]
Before this patch, although chgserver drops repo object by setting it to None,
there is another side effect loading a repo: setting bundle.mainreporoot.
This patch explicitly sets it to empty to undo the side effect. It will make
chg pass test-strip.t.
It's been superseded by config/env hash. A log message is simplified as we no
longer need a diff of environment variables. Also, _loadnewui() is changed to
require args since it can't copy old --config values without args.
Before this patch, chgserver will use repo ui as dispatch.request.ui, while
req.ui is designed to be global ui without repo config.
Passing repo ui as dispatch.request.ui leads to repo.ui being incorrect, which
can lead to unwanted results. For example, if the repo config has [extensions],
it could affect which localrepository.featuresetupfuncs get executed and the
repo may have an incorrect list of supported requirements.
This patch changes _renewui to return both global ui and repo ui. The global
ui is passed to req.ui, and the repo ui is used to calculate confighash. It
will make chg pass test-largefiles-misc.t and test-requires.t, which are both
related to repo requirements.
Adds a hint to histedit comment reminding user about enabled dropmissing.
This will make the enabled dropmissing more visible. The example comment:
# Edit history between 5abd0a5c28d1 and b54649a8a63f
#
# Commits are listed from least to most recent
#
# You can reorder changesets by reordering the lines
#
# Commands:
#
# e, edit = use commit, but stop for amending
# m, mess = edit commit message without changing commit content
# p, pick = use commit
# b, base = checkout changeset and apply further changesets from there
# d, drop = remove commit from history
# f, fold = use commit, but combine it with the one above
# r, roll = like fold, but discard this commit's description
#
# Deleting a changeset from the list will DISCARD it from the edited history!
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.
