Summary:
Moves ctreemanifest into hgext/extlib/. It will be built in a later
step when we add cstore to the build.
Test Plan: make local && cd tests && ./run-tests.py
Reviewers: #mercurial
Differential Revision: https://phabricator.intern.facebook.com/D6678844
Summary:
Move the rust libraries and extensions to their new locations, and integrate
them with the hg-crew setup.py.
Test Plan: Run `python setup.py build` and verify rust extensions are built.
Reviewers: durham, #mercurial
Reviewed By: durham
Subscribers: fried, jsgf, mitrandir
Differential Revision: https://phabricator.intern.facebook.com/D6677251
Tasks: T24908724
Signature: 6677251:1515450235:920faf40babbce9b09e3283ff9ca328d1c5c51e6
Summary:
Move hgsql into the hgext directory, and the tests to tests/test-hgsql-*.
Update the tests to refer to the new places for things.
Test Plan: Run the hgsql tests and make sure they pass.
Reviewers: #sourcecontrol
Differential Revision: https://phabricator.intern.facebook.com/D6660499
Tasks: T24908724
In preparation for adding more conditions that will disable IMM, let's make
this framework more extensible and log the reason IMM wasn't used.
The `whynotimm` variable name matches the `why_not_eden` name in
`hg/eden/__init__.py`.
Differential Revision: https://phab.mercurial-scm.org/D1785
Some callers to rebase.rebase(), like `_moverelative` in `fbamend/movement.py`,
wrap the entire rebase call in a transaction. This raises havoc when IMM tries
to retry the rebase when it hits merge conflicts, because the abort will fail
the whole transaction, not the subset. It also fails at the end, losing any
conflict resolution, as @sid0 noticed.
The right long-term fix that @quark and I have discussed is to change the
restarting logic such that it doesn't abort at all, but simply switches between
IMM and non-IMM fluidly for each commit, which has other nice properties. In
the meantime this will do for now.
Differential Revision: https://phab.mercurial-scm.org/D1782
We need hash-preserving unamend. Therefore remove the core version.
(grafted from 86e055fbb0c974e041dbd72cd95df6e3b37a0f6b)
(grafted from 129f15c3acd81d4390212430ea6b500412bc74ab)
(grafted from fbb42eb996d5bcddac4ba4e86a915a3bc62b3e16)
02c30db0443d (lfs: add a repo requirement for this extension once an lfs
file is committed) introduced a regression that prevents committing file
deletion. This patch fixes that.
Differential Revision: https://phab.mercurial-scm.org/D1717
This will allow developers to test against various server implementations. I
didn't put it under [devel] because it's possible that some user needs to use it
in the field.
As we were trying to transition off of the non production lfs-test-server for
further experimenting, one of the problems we ran into was interoperability. A
coworker setup gitbucket[1] to act as the blob server, tested with git, and
passed it off to me. But push failed with a message saying "abort: LFS server
returns invalid JSON:", and then proceeded to dump a huge HTML page to the
screen. It turns out that it is assuming that git is the only thing that wants
to do a blob transfer, and everything else is a web browser wanting HTML.
It's only a single data point, but I suspect other things may be doing this too.
RFC7231 gives an example [2] of listing multiple products in decreasing order of
significance. Since the standard provides for this, and since it works with the
one problematic server I found, I'm just enabling this by default for a better
UX.
There's nothing significant about the version of git chosen, other than it is
the current version.
[1] https://github.com/gitbucket/gitbucket/
[2] https://tools.ietf.org/html/rfc7231#page-46
I don't see why unamend should be disallowed when allowunstable is
set. By switching to rewriteutil.precheck() we fix that and get more
consistent error messages (and some additional ones).
Differential Revision: https://phab.mercurial-scm.org/D1682
This significantly speeds up lfs prefetch. With fast network we are
seeing ~50% improvement of overall prefetch times
Because of worker's API in posix we do lose finegrained progress update and only
see progress when a file finished downloading.
Test Plan:
Run tests:
./run-tests.py -l test-lfs*
....
# Ran 4 tests, 0 skipped, 0 failed.
Run commands resulting in lfs prefetch e.g. hg sparse --enable-profile
Differential Revision: https://phab.mercurial-scm.org/D1568
The branch information was properly preserved in the changeset, but the
"active" branch of the working copy could be lost (the branch of the base
being used).
Histedit used to behave properly in this regard but the case was not tested
and regressed 4 years ago in c038baa4b6f0.
This effectively conditionalizes 7ac081713920. Some Linux distributions (like
CentOS 7) use really old versions, and the change referenced was causing
exceptions to be thrown.
Even though the deprecation warning says 'since 2.5.0', it wasn't marked as such
in 2.5.1, but is by 2.6.0. This was tested with 2.4.2 and 2.6.0 with
PYTHONWARNINGS=::DeprecationWarning, and both paths were exercized.
Previously, the largefile for a dropped standin would be deleted here, and then
restored from the cache. This had the effect of clobbering uncommitted changes
if a revert caused the file to be forgotten, which is not what happens with a
normal file. Now the removal and update is skipped for dropped largefiles, and
the corresponding standin is deleted from disk.
This was noticed when working on issue5738 because the forgotten standin files
were left behind, and that changes the behavior of the next rename to that
directory. My first attempt was to cleanup the standins before calling this.
That failed, because this function deletes the largefile if the corresponding
standin is missing.
This function is called by the revert command, merge (and therefore update), and
patch, via the scmutil.marktouched() override. So it should be pretty narrow in
scope.
I didn't mark issue5738 as fixed because the move related issues can still
happen if the main tree and the .hglf subtree get out of sync somehow. I don't
see an easy fix for that, but that should be an edge case. If whoever queues
this thinks it is good enough to close out the bug and can cram it into the
summary, go for it.
The `hg lfconvert --to-normal` command uses the convert extension internally to
work its magic, but that produced devel-warn messages if the convert extension
wasn't loaded by the user. The test in 658e7a6d93e0 (modified here) wasn't
showing the warnings because the convert extension was loaded via $HGRCPATH.
Most of the config options default to None/False, but 'hg.usebranchnames' and
'hg.tagsbranch' are supposed to default to True and 'default' respectively.
The first iteration of this was to ui.setconfig() inside lfconvert, to force the
convert extension to load. But there really is no precedent for doing this, and
check-config complained that 'extensions.convert' isn't documented. Yuya
suggested this alternative.
This partially backs out 448e09d8859d.
These config items control share behavior that is implemented in core.
Since the functionality is implemented in core, extensions may
leverage it.
Mozilla has one such extension. And, it needs to access share.pool.
Before this patch, a devel warning regarding accessing an unregistered
config option would be issued unless the share extension were loaded.
Moving the registration of the config options to core fixes this.
If the legacy pager extension is enabled, a pager is started through repo.ui
at dispatch._runcommand(). After that, mqcommand() creates a qrepo with a
fresh repo.baseui, at which point pager information was lost and another pager
would be spawned by the modern pager interface.
This is a minimal workaround for the problem.
5c25fe7fb1e broke something in the hgsubversion test path, causing it raise an
abort (Abort: nothing to merge) during a perfectly good rebase. I tracked it
down to this change. It's probably not hgsubversion related.
I suspect that using the same `wctx` from before the initial update causes
problems with the wctx's cached manifest property. I noticed we also sometimes
stick random gunk on the wctx object in other places (like in `copies.py`) so
it's probably best to reset it for now.
The line I added before was actually useless since we don't pass wctx to the
initial `merge.update`, so it defaults to `repo[None]`. So I just removed it.
Differential Revision: https://phab.mercurial-scm.org/D1679
committablefilectx has three subclasses: workingfilectx, memfilectx,
and overlayfilectx. committablefilectx takes an optional (change) ctx
instance to its constructor. If it's provided, it's set on the
instance as self._changectx. If not, that property is supposed to be
defined by the class. However, only workingfilectx does that. The
other two will have the property undefined if it's not passed in the
constructor. That seems bad to me. This patch makes the changectx
argument to the memfilectx constructor mandatory because that fixes
the failure I ran into. It seems like we should also fix the
overlayfilectx case.
Differential Revision: https://phab.mercurial-scm.org/D1658
This is just a very simple start, but verifies some of the basic cases of an
in-memory rebase.
Differential Revision: https://phab.mercurial-scm.org/D1652
In order to fix the missing lfs store after an upgrade, I attempted to walk the
store vfs to hardlink to the upgraded repo's store. But the custom join()
clashes with the default walk() implementation. First, 'path=None' blew up in
the regex matcher, because it wanted a string. But even if that is fixed, the
join to walk the root of the vfs wouldn't match the required xx/xx...xx pattern.
The first cut of this was a copy/paste/tweak of the base implementation, but
this version of walk() hides the internal directories, and treats the vfs as a
flat store. I think this makes sense because most vfs methods call join() on
input paths, which wants the simple oid format. It also relieves the caller
from having to deal with bogus files/directories in the store.
Keys of keyword arguments must be str(unicode) on Python 3. The transformer
which we use on Python 3, appends b'' in front of each string literal, so this
may lead in KeyError or None return even when the key is present by we are using
bytes value and it's stored in unicodes. This patch and all the similar patches
handle this by either converting the keys of kwargs to bytes using
'pycompat.byteskwargs()' or adding r'' so that the transformer won't append
b''.
This next 23 patches follows the above mentioned way to handle keyword
arguments.
Differential Revision: https://phab.mercurial-scm.org/D1624
The extensions wrap the necessary function to ensure the 'lfs' requirements
won't be dropped.
It is now possible to run `hg debugupgraderepo` on a repository with lfs.
As described in the comment, rebasing the working copy parent with in-memory
merge, and then updating to the new commit, isn't much faster because of the
extra overhead of uppdating. Best to leave it off in that case.
This commit makes deploying in-memory merge via an extension easier, because
you can just set `inmemory=True` based on some config or probability, and this
will turn off the cases where it's not desired.
Differential Revision: https://phab.mercurial-scm.org/D1616
Since highlight is only relevant for servers, it seems worthwhile to
just trigger this eagerly, which avoids really weird traceback
problems caused by demandimport messing with some of the lexer plugins.
Differential Revision: https://phab.mercurial-scm.org/D1619
The fsmonitor extension should send state-enter and state-leave
notifications to watchman when the wlock is acquired/release, respectively.
This will allow watchman and watchman subscribers to customize behavior based
on whether source control operations are occurring.
Test Plan:
Tested checkout, update and working copy changes with extension enabled.
Differential Revision: https://phab.mercurial-scm.org/D1612
Remove working copy change and transaction notifications. We were relying
upon callbacks on transaction function. This caused issues with lock ordering.
A different approach will be adopted in a subsequent commit.
Differential Revision: https://phab.mercurial-scm.org/D1611
The extensions wrap the necessary function to ensure the 'largefiles'
requirements won't be dropped.
It is now possible to run `hg debugupgraderepo` on a repository with largefiles.
`dirstate._nonnormalset` has been moved to `dirstate._map.nonnormalset` by
822ff2522caf (dirstate: move nonnormal and otherparent sets to dirstatemap)
and is guaranteed to be existed.
Let's update fsmonitor code to use the new `nonnormalset`. Thix fixed a perf
regression that slows down `hg status` by 0.5 seconds in one of our
production repos.
Differential Revision: https://phab.mercurial-scm.org/D1184
In obsmarker we can't store keys and values of more than 255 bytes in metadata.
If we try to do so, ProgrammingError is raised. The note flag to amend stores
the note in obsmetadata. If a user will try to store a larger note, he will
encounter ProgrammingError which is wrong. We must error out early.
Thanks to Yuya for warning about this.
Differential Revision: https://phab.mercurial-scm.org/D1179
chgserver.py is also checking the config and will get:
devel-warn: accessing unregistered config item:
'commands.show.aliasprefix' at:
mercurial/chgserver.py:109
if the config is not registered.
Differential Revision: https://phab.mercurial-scm.org/D1178
These were added in 24a87d506bbd. Attempting to run the test harness
with fsmonitor enabled spews a whole bunch of devel warnings due to
these options not be declared.
Differential Revision: https://phab.mercurial-scm.org/D1176
fsmonitor can significantly speed up operations on large working
directories. But fsmonitor isn't enabled by default, so naive users
may not realize there is a potential to make Mercurial faster.
This commit introduces a warning to working directory updates when
fsmonitor could be used.
The following conditions must be met:
* Working directory is previously empty
* New working directory adds >= N files (currently 50,000)
* Running on Linux or MacOS
* fsmonitor not enabled
* Warning not disabled via config override
Because of the empty working directory restriction, most users will
only see this warning during `hg clone` (assuming very few users
actually do an `hg up null`).
The addition of a warning may be considered a BC change. However, clone
has printed warnings before. Until recently, Mercurial printed a warning
with the server's certificate fingerprint when it wasn't explicitly
trusted for example. The warning goes to stderr. So it shouldn't
interfere with scripts parsing meaningful output.
The OS restriction was on the advice of Facebook engineers, who only
feel confident with watchman's stability on the supported platforms.
.. feature::
Print warning when fsmonitor isn't being used on a large repository
Differential Revision: https://phab.mercurial-scm.org/D894
This patch adds support to rebase to show the changes in node once the rebase is
complete. This will be extremely helpful for automation purposes and editors
such as Nuclide.
The output is a dictionary of predecessor hash as key and a list of successors'
hashes. The successors one is a list as there can be many successors for a single
predecessor in case of split and it will good to have a generic output format.
This patch adds tests for the same. A new file is created for the patch as
existing files related to rebase has their own purpose and there will be more
formatter support coming for rebase in next cycle.
Thanks to Jun for suggesting to use fm.data().
Differential Revision: https://phab.mercurial-scm.org/D1173
This will be used to setup unsharing subrepos. Usually cmdutil is used for
this purpose. But the implementation needs hg.copystore(), and the hg module
already imports cmdutil.
Grouping all evolution related-config under the experimental.evolution
namespace would helps the future migration outside [experimental].
Differential Revision: https://phab.mercurial-scm.org/D1155
In the future, the --inmemory flag might be deprecated in favor of something more
intelligent (for example, always rebasing in-memory if the working copy parent
isn't in the rebaseset). But we might keep it as a way to explicitly force IMM
on or off.
Differential Revision: https://phab.mercurial-scm.org/D1232
This was intended to be done by D470. But there was a minor documentation
issue. The feature is quite usable now so it gets formally documented and
enabled.
There is no behavior change for people not using the `SRC` or `ALLSRC` in
rebase destination revset.
.. feature:: Rebase with different destination per source revision
Previously, rebase only supports one unique destination. Now ``SRC`` and
``ALLSRC`` can be used in rebase destination revset to precisely define
destination per each individual source revision.
For example, the following command could move some orphaned changesets to
reasonable new places so they become no longer orphaned::
hg rebase
-r 'orphan()-obsolete()'
-d 'max((successors(max(roots(ALLSRC) & ::SRC)^)-obsolete())::)'
Differential Revision: https://phab.mercurial-scm.org/D1063
This is the same mechanism in place for largefiles, and solves several problems
working with multiple local repositories. The existing largefiles method is
reused in place, because I suspect that there are other functions that can be
shared. If we wait a bit to identify more before `hg cp lfutil.py ...`, the
history will be easier to trace.
The push between repo14 and repo15 in test-lfs.t arguably shouldn't be uploading
any files with a local push. Maybe we can revisit that when `hg push` without
'lfs.url' can upload files to the push destination. Then it would be consistent
for blobs in a local push to be linked to the local destination's cache.
The cache property is added to run-tests.py, the same as the largefiles
property, so that test generated files don't pollute the real location. Having
files available locally broke a couple existing lfs-test-server tests, so the
cache is cleared in a few places to force file download.
Largefiles puts everything into a flat directory, while lfs divides files up by
creating subdirectories consisting of the first two characters of the hash.
Therefore, pointing at the largefiles cache won't work.
We do the same thing on clone for the largefiles extension, as a convenience.
Similar to largefiles, it's probably safer to only enable this extension on a
per repo basis because it is trivial to add an lfs file. And that gives the
repository some centralized VCS characteristics.
The _unamenddirstate() function was inspired by _uncommitdirstate() function as
the logic was same but we were unable to use the latter function directly. So
previous patch introduced the _unamenddirstate() function and now this patch
unifies both the function and we have a _fixdirstate() function.
Adding function in previous patch and unifying in a later patch makes the
reasoning easier and also leaves the last patch dedicated to what it is meant to
be.
Differential Revision: https://phab.mercurial-scm.org/D971
unamend extension adds an unamend command which undoes the effect of the amend
command. This patch moves the unamend command from that extension to uncommit
extension and this one does not completely undoes the effect of amend command as
it creates a new commit, rather than reviving the old one back.
This also adds tests for the same.
.. feature::
A new unamend command in uncommit extension which undoes the effect of the
amend command by creating a new changeset which was there before amend and
moving the changes that were amended to the working directory.
Differential Revision: https://phab.mercurial-scm.org/D821
This covers both the vanilla repo -> lfs repo and largefiles -> lfs conversions.
The largefiles extension adds the requirement directly, because it has a
dedicated command to convert. Using the convert extension is better, because it
supports more features.
I'd like ideas about how to ensure that converting away from lfs works on all
files. (See comments in test-lfs.t)
The next patch will wrap the conversion code, in order to write out a
requirement for 'lfs' when appropriate. Wrapping convcmd.convertsink() in an
afterloaded callback works fine when the convert extension is enabled by the
user. The problem here is that lfconvert uses the convert extension, whether or
not it was formally enabled by the user.
My first attempt was to have lfs install an afterloaded callback that would wrap
the convert sink if convert was loaded, or wrap lfconvert if it wasn't. Then
the lfconvert override could install an afterloaded callback to try wrapping the
convert sink again, before calling the original lfconvert. But that breaks down
if largefiles can't load the convert extension on the fly. [1] Further, some
tests were failing with an error indicating that the size of the afterloaded
list changed while iterating it.
Yuya mentioned that maybe some bits of convert could be moved into core, but I'm
not sure where to draw that line. The convertsink() method depends on the list
of sinks, which in turn depends on the sink classes.
[1] https://www.mercurial-scm.org/pipermail/mercurial-devel/2017-November/108038.html
This seems like basic info to have, and will be used shortly when deciding
whether or not to wrap the class for lfs conversions.
The other option is to just add a function to each class. But this seems better
in that the strings aren't duplicated, and the constructor for most of these
will run even if the VCS isn't installed, so it's easier to catch errors.
Largefiles does the same thing (also delayed until the first largefile commit),
to prevent access to the repo without the extension. In the case of this
extension, not having the extension loaded while accessing an lfs file results
in cryptic errors about "missing processor for flag '0x2000'". If enabled
locally but not remotely, the cryptic error message is about no common
changegroup version. (It wants '03', which is currently experimental.)
The largefiles extension looks for any tracked file that starts with '.hglf/'.
Unfortunately, that doesn't work here. I didn't see any way to get the files
that were just committed, without doing a full status. But since there's no
secondary check on adding an lfs file once the extension is loaded and a
threshold set, the best practice is to only enable this locally on a repo that
needs it. That should minimize the unnecessary overhead for repos without an
lfs file.
The JSON output of nodechanges will help in automation and to improve editor
integrations such as for Nuclide.
Differential Revision: https://phab.mercurial-scm.org/D1348
The purpose of this is the same as the built-in largefiles extension- to handle
huge files outside of the normal storage system, generally to keep the amount of
data cloned to a lower amount. There are several benefits of implementing the
git-lfs protocol, instead of using the largefiles extension:
- Bitbucket and Github support (and probably wider support in 3rd party
hosting sites in general). [1][2]
- The number of hg internals monkey patched are several orders of magnitude
lower, so it will be easier to reason about and maintain. Future commands
will likely just work, without requiring various wrappers.
- The "standin" files are only written to the filelog, not the disk. That
should avoid weird edge cases where the largefile and standin files get out
of sync. [3] It also avoids the occasional printing of the "hidden" standin
file in various messages.
- Filesets like size() will work, even if the file isn't present. (It always
says 41 bytes for largefiles, whether present or not.)
The only place that I see where largefiles comes out on top is that it works
with `hg serve` for simple sharing, without external infrastructure. Getting
lfs-test-server working was a hassle, and took awhile to figure out. Maybe we
can do something to make it work in the future.
Long term, I expect that this will be highly preferred over largefiles. But if
we are to recommend this to largefile users, there are some UI issues to
bikeshed. Until they are resolved, I've marked this experimental, and am not
putting a pointer to this in the largefiles help. The (non exhaustive) list of
issues I've seen so far are:
- It isn't sufficient to just enable the largefiles extension- you have to
explicitly add a file with --large before it will pay attention to the
configured sizes and patterns on future adds. The justification being that
once you use it, you're stuck with it. I've seen people confused by this,
and haven't liked it myself. But it's also saved me a few times. Should we
do something like have a specific enabling config setting that must be set
in the local repo config, so that enabling this extension in the user or
system hgrc doesn't silently start storing lfs files?
- The largefiles extension adds a repo requirement when the first largefile is
committed, so that the extension must always be enabled in the future. This
extension is not doing that, and since I only enabled it locally to avoid
infecting other repos, I got a cryptic error about missing flag processors
when I cloned. Is there no repo requirement due to shallow/narrow clone
considerations (or other future advanced things)?
- In the (small amount of) reading I've done about the git implementation, it
seems that the files and sizes are stored in a tracked .gitattributes file.
I think a tracked file for this would be extremely useful for consistency
across developers, but this kind of touches on the tracked hgrc file
proposal a few months back.
- The git client can specify file patterns, not just sizes.
- The largefiles extension has a cache directory in the local repo, but also a
system wide one. We should probably implement a system wide cache too, so
that multiple clones don't have to refetch the files from the server.
- Jun mentioned other missing features, like SSH authentication, gc, etc.
The code corresponds to c0492b73c7ef in hg-experimental. [4] The only tweaks
are to load the extension in the tests with 'lfs=' instead of
'lfs=$TESTDIR/../hgext3rd/lfs', change the import in the *.py test to hgext
(from hgext3rd), add the 'testedwith' declaration, and mark it experimental for
now. The infinite-push, p4fastimport, and remotefilelog tests were left behind.
The devel-warnings for unregistered config options are not corrected yet, nor
are the import check warnings.
[1] https://www.mercurial-scm.org/pipermail/mercurial/2017-November/050699.html
[2] https://bitbucket.org/site/master/issues/3843/largefiles-support-bb-3903
[3] https://bz.mercurial-scm.org/show_bug.cgi?id=5738
[4] https://bitbucket.org/facebook/hg-experimental
As part of the dirstate refactor, fsmonitor was updated to directly access the
inner map of the dirstatemap object.
Dirstatemap reimplementations may not use a map like this, so only access it if
it is there.
Differential Revision: https://phab.mercurial-scm.org/D1346
The set-like object returned by dirstate.dirs may be difficult for other
implementations of the dirstate to provide, and is unnecessary as it is
only ever used for __contains__. Instead, provide an explicit method for
testing for a directory.
.. api::
dirstate no longer provides a `dirs()` method. To test for the existence of
a directory in the dirstate, use `dirstate.hasdir(dirname)`.
Differential Revision: https://phab.mercurial-scm.org/D1345
.. feature::
Let 'hg rebase' avoid content-divergence by skipping obsolete
changesets (and their descendants) when they are present in the rebase
set along with one of their successors but none of their successors is
in destination.
In the following example, when trying to rebase 3:: onto 2, the rebase
will abort with "this rebase will cause divergence from: 4":
o 7 f
|
| o 6 e
| |
| o 5 d'
| |
x | 4 d (rewritten as 5)
|/
o 3 c
|
| o 2 x
| |
o | 1 b
|/
o 0 a
By excluding obsolete changesets without a successor in destination (4
in the example above) and their descendants, we make rebase work in this
case, thus giving:
o 11 e
|
o 10 d'
|
o 9 c
|
o 8 b
|
| o 7 f
| |
| | x 6 e (rewritten using rebase as 11)
| | |
| | x 5 d' (rewritten using rebase as 10)
| | |
| x | 4 d
| |/
| x 3 c (rewritten using rebase as 9)
| |
o | 2 x
| |
| x 1 b (rewritten using rebase as 8)
|/
o 0 a
where branch 4:: is left behind while branch 5:: is rebased as expected.
The rationale is that users may not be interested in rebasing orphan
changesets when specifying a rebase set that include them but would
still want "stable" ones to be rebased. Currently, the user is suggested
to allow divergence (but probably does not want it) or they must specify
a rebase set excluding problematic changesets (which might be a bit
cumbersome). The approach proposed here corresponds to "Option 2" in
https://www.mercurial-scm.org/wiki/CEDRebase.
We extend _computeobsoletenotrebased() so that it also return a set of
obsolete changesets in rebase set without a successor in destination but
with at least one successor in rebase set. This
'obsoletewithoutsuccessorindestination' is then stored as an attribute
of rebaseruntime and used in _performrebasesubset() to:
* filter out descendants of these changesets from the revisions to
rebase;
* issue a message about these revisions being skipped.
This only occurs if 'evolution.allowdivergence' option is off and
'rebaseskipobsolete' is on.
The keys of keyword arguments must be str on Python 3 which is unicode. This
patch make sure we pass keyword arguments with keys are str everywhere in this
file and access the keys depending on whether they are bytes or str.
This patch uses pycompat.{byteskwargs|strkwargs} and somewhere it also added r''
to prevent transformer from adding a b'' over there.
Differential Revision: https://phab.mercurial-scm.org/D974
The shelve extensions import and call rebase content without loading the
extension. This is problematic as the config items rebase uses are not
declared and the default value are not set, etc...
The shelve extension should be using core utilities only and the necessary bit
should be moved from rebase into core. In the meantime, I'm taking a small
step to get config registration completed with minimal overhead. The rebase
extension is shipped with core so registering its config option within core is
not a big issue.
This is the last step needed before we can install a warning that enforces all
config to be registered.
The acl extension is usually setup through hooks and never directly activated.
This means the config item declared in the extension are not loaded.
We add the necessary logic to make sure the extensions are loaded before the hook
run.
Previously, only the top level repo was shared, and then any subrepos were
cloned on demand. This is problematic because commits to the parent repo would
write an updated .hgsubstate to the share source, but the corresponding subrepo
commit would be stuck in the local subrepo. That would prevent an update in the
source repo. We already go to great lengths to avoid having inconsistent repos
(e.g., `hg push -r rev` will push _everything_ in a subrepo, even if it isn't
referenced in one of the parent's outgoing commits). Therefore, this seems like
a bug fix, and there's no option to get the old behavior. I can't imagine the
previous behavior was useful to anybody.
There shouldn't be an issue with svn, since it is centralized. Maybe --git-dir
can be used for git subrepos, but I'll leave that to someone more familiar with
git.
An integer was previously being implicitly returned from commands.share(), which
caused dispatch() to start crashing when changing over to returning the shared
repo. All error paths appear to raise, so this can be hardcoded to success.
The clone command checks for 'is None' in a similar pattern, but since
hg.clone() always returns a tuple, that seems wrong?
.. fix:: Issue 5675
Creating a share of a repository with a Mercurial subrepository will now
share the subrepository.
and
.. bc::
Mercurial subrepositories are now shared instead of cloned when the parent
repository is shared. This prevents dangling subrepository references in the
share source. Previously shared repositories with cloned subrepositories
will continue to function unchanged.
This will help us in determining easily that whether fuzzywuzzy is loaded or not
loaded in any of the function.
Differential Revision: https://phab.mercurial-scm.org/D1120
While producing releasenotes for (4.3::), releasenotes aborts with error because
of some bad formatting of releasenotes in some commits. Instead of aborting,
this adds warning message which will help us in skipping them and telling user
about it.
Differential Revision: https://phab.mercurial-scm.org/D1097
If fuzzywuzzy is note present, we will not be having the capability to merge
existing releasenotes with the new releasenotes on the similarity basis.
The merging will still work good for exact same releasenotes entries.
Differential Revision: https://phab.mercurial-scm.org/D1096
This patch utilises the functionality added in previous patches and adds a flag
to amend command in hgext/amend to add a note to the amend. Since the note is
stored in the obsmarker metadata, this will only be useful when obsmarker
creation is enabled, otherwise this is no-op.
Not adding releasenotes part as we yet don't have a functionality in core to
show the note.
Differential Revision: https://phab.mercurial-scm.org/D1095
D942 removed the experimental config 'histeditng'. This is a leftover
which should have been removed in that commit. Therefore, this commit completes
the cleanup.
Test Plan:
Ran all the tests.
Differential Revision: https://phab.mercurial-scm.org/D1123
With in-memory merge, copy information needs to be stored in-memory, not in the
dirstate.
To make this transition easy, move the existing dirstate-based approach to
workingfilectx; that way, other implementations can choose to store it
somewhere else.
Differential Revision: https://phab.mercurial-scm.org/D1106
The function document says that it returns true when the fragment can be merged,
but if you see the function just above it which is similar(), it writes already
exists thing if return value from similaritycheck() is False which is just
opposite of the doc. This patch fixes that.
Differential Revision: https://phab.mercurial-scm.org/D1119
