Summary: The binhunk is for binary data, therefore we need to use byte strings.
Reviewed By: xavierd
Differential Revision: D20290069
fbshipit-source-id: 9cd763b76df389a1f7b65aecf0be4aa36a85cf91
Summary: The .encode('hex') isn't available in Python3, codecs.encode needs to be used.
Reviewed By: DurhamG
Differential Revision: D20927989
fbshipit-source-id: cd0ecdbcbf0ab6391b37f44e7b38a3ffabf91340
Summary:
In Python3, the error returned from binascii.unhexlify changed, from a generic
TypeError to a binascii.Error. Therefore, wrap the binascii function and catch
the binascii.Error before raising a TypeError.
Reviewed By: DurhamG
Differential Revision: D20924129
fbshipit-source-id: 33f852ea97396af715ef73630e0dd1b4324eb707
Summary:
I can't say that I understand `mdiff.splitnewlines`. In my test it does not
behave the way it reads and I don't know why. The stripping that it's supposed
to do doesn't happen for some reason. It behaves like splitlines.
I believe that rcutil used '\n' for line termination because it was relying on
Python to do the conversion to system line end. I updated to use os.linesep
now that we encode the contents.
Reviewed By: quark-zju
Differential Revision: D20935377
fbshipit-source-id: 0958fdff03950ab0a4b2da02e4333b5438ac5c70
Summary:
Bytes and Str usages mostly. __iter__ seems to have been incorrectly
converted to python 3 previously.
Reviewed By: xavierd
Differential Revision: D20933166
fbshipit-source-id: 10e63e90bd83c70a51dd808e9b5073ab8d766e71
Summary: We should read/write to it via as utf8.
Reviewed By: DurhamG
Differential Revision: D20923404
fbshipit-source-id: 86cdc329395d60c88637f24d3c7c5caedcc7111a
Summary:
The computation of commit obsolescence is inconsistent. If we compute the full
set of obsolete commits in `mutation.obsoletecache.obsoletenodes`, then we
correctly ignore public commits as they cannot be obsolete.
However, if we compute the obsolescence state for a single public commit with
`mutation.obsoletecache.isobsolete`, and that commit somehow has a visible
successor, then we will incorrectly consider the commit as obsolete.
Similarly, `allpredecessors` and `allsuccessors` should stop when they hit a
public commit.
Reviewed By: quark-zju
Differential Revision: D20892778
fbshipit-source-id: 223cb8b2bc9f2f08124df6ff51c2eb208bb8eb5f
Summary: This makes the tracing features easier to use.
Reviewed By: DurhamG
Differential Revision: D19797703
fbshipit-source-id: fb5cb17cd389575cf0134a708bcd9df3b90e9ab4
Summary: Print out a command that can be copied and executed to make `--keeptmp` more handy.
Reviewed By: sfilipco
Differential Revision: D20829140
fbshipit-source-id: 7976e3f64fd423425ec29634a53a34f7b5e091d0
Summary:
Add a command to print visibleheads. This was part of my attempt to check if
visibleheads can accidentally include public commits and if there are a way
to remove it. I ended up thinking D20808884 might actualy solve the only case
that visibleheads include public heads.
I also tried to add strong verification so that the visibility layer never
writes public nodes. That's for non-narrow-heads use-cases. However, the
phasescache + repoview layer is kind of messy in a way that inside a
transaction there is only one "repo" that has the right in-memory, dirty
"phasescache" and other repos will load the (stale, wrong) phasescache from
disk. That means if we test phases in visibility before transaction flushes,
we won't be able to access the latest phases information correctly. So I
gave up this approach too.
Anyway, I wasn't able to add a new interesting test, but the utility built for
the test seems useful. Therefore this change.
Reviewed By: sfilipco
Differential Revision: D20829136
fbshipit-source-id: 5ebafefac820ebb4044db63b7892ffaa341c0573
Summary:
Make the error cleaner and more actionable. We don't autopull the commit
because the revset layer might be not ready for it (ex. it expects commit
graph to be immutable and might have done some calculations based on the
old graph already).
Reviewed By: sfilipco
Differential Revision: D20845159
fbshipit-source-id: c51f2f52c612ff14a88fb891c10d1faad1094635
Summary:
The old linear changelog search does not scale and does not work with segmented
changelog, which makes commit data lazy. The "forksearch" is also problematic as
it can produce non-deterministic results. Let's disable the linear search by
default with the intention to remove it if nobody complains.
Reviewed By: sfilipco
Differential Revision: D20845161
fbshipit-source-id: 6911035f146e15c88925217ee9940db59ea2d1c1
Summary:
The manifest node is hard for debugging. Attach the commit as the context and
print it out.
Reviewed By: sfilipco
Differential Revision: D20829139
fbshipit-source-id: ff65d902f56bc79c2d5f2c3ec9cf79a620fd70fc
Summary:
Loose files makes it easier to interact with a Mercurial server for tests, use
it instead of an IndexedLog.
Reviewed By: DurhamG
Differential Revision: D20786432
fbshipit-source-id: 61c1fc601d9a6ed157c5add9748e40840b081870
Summary: The template should use mutation instead of obsutil if mutation is enabled.
Reviewed By: markbt, simpkins
Differential Revision: D20901109
fbshipit-source-id: a2b587ddf2a03965886f753e54e075d5d9064f05
Summary:
When syncing, if the local copy of the remote bookmark is `None` then the
remote bookmark has been deleted, and shouldn't be added to the set of new
remote bookmarks.
Reviewed By: DurhamG
Differential Revision: D20855909
fbshipit-source-id: 84a7a78ec0ab179e4a14d946b37f496f3dbde03a
Summary:
When falling back to convert_revision to get the svnrev for a commit to return
it as a globalrev, it seems like it would make sense to verify that the
convert_revision is indeed a svnrev (and not, say, a git commit hash from
hggit).
Reviewed By: farnz
Differential Revision: D20891268
fbshipit-source-id: 2451ad787fcce7b10b6a405f2855313ca51f5b3e
Summary:
Use modern utilities for this test. This makes the setup portion much shorter.
The test content changed a bit as the configuration is changed - both clients
have selectivepull enabled.
Reviewed By: sfilipco
Differential Revision: D20829137
fbshipit-source-id: d2f29d162172e149d7140925e7d3801707484df2
Summary:
This makes writing tests easier.
It was part of D20504732.
Reviewed By: sfilipco
Differential Revision: D20829138
fbshipit-source-id: e9309e099a13d0a509eff707ae229bf8b7a9c231
Summary:
This makes it easier to spot typos.
The config sparse.missingwarning affects everytime a sparse profile is used.
In this case we just want to check at "enableprofile" time. So avoid using
that config option.
Reviewed By: DurhamG
Differential Revision: D20846313
fbshipit-source-id: 79f80d5e01abfe1633f2597074e9acb5cda60fec
Summary:
The IndexedLog code uses a lock file to lock a directory on Windows, make
sure we account for that.
Reviewed By: DurhamG
Differential Revision: D20818882
fbshipit-source-id: 7e9aa255354d36899ad57168311a4276d448dc07
Summary:
For our HgExternalSync jobs that pull from git, we don't really use most of the
bells and whistles of hggit. Notably, we don't care about bookmarks: we only
ever pull master, we never update to it, we only ever look at `-r tip`.
However, we do care about things that are actually much harder to fit in a
world where we try to pretend the remote git repository is actually a hg
repository we can pull from.
Notably, we'd like to enforce limits on how many commits we pull (and convert)
at a time, so that if we fall behind a little bit, we don't start falling even
more behind by having to convert bigger and bigger batches of commits. If we're
trying to pretend fetching from git and converting commits is actually a pull,
then that seems harder to pull off (we'd need to somehow rewind the remote head
we're pulling before importing it).
So, this adds a new external-sync command to hggit that basically the bare
minimum that we do need. It lets you specify a git remote and a head you care
about, and import up to N commits from it. That's it — no bookmarks are updated
or anything (but the git-mapfile is, of course). The only thing that changes is
your commits.
If you actually want to interact with your git repository on an ongoing basis
as if it were a remote hg repository, this is completely useless, but that
isn't what we actually do, so that should be OK.
As part of this, I've modified a few other parts of git_handler to remove
places where we called a `uri` `remote_name` (which is a bit confusing), and a
place where we were asking for a `remote_name` parameter that I don't have
here, but which we also didn't actually need (in `import_git_objects`).
Reviewed By: farnz
Differential Revision: D20836601
fbshipit-source-id: 96230e6e8269d0472404414948fd2f02aa98d79c
Summary:
On Windows, we have to do a bit of dance for Windows to stop complaining
about ui.ssh.
Reviewed By: DurhamG
Differential Revision: D20817712
fbshipit-source-id: acbda636fe114fd616dee89b2c4d1c9ff26470bf
Summary: This will allow bash users to use things like `hg commit -l <(echo foo)`.
Reviewed By: krallin
Differential Revision: D20810653
fbshipit-source-id: 42e420e608d41704387a9011cf14a28f92192e5d
Summary:
This updates fastheaddiscovery to use an unfiltered repository when it attempts
to check if the nodes the server sent are present locally.
Reviewed By: quark-zju
Differential Revision: D20792006
fbshipit-source-id: 14ba9605d79ba54f3f4143d6d8ec65357e3d8c07
Summary:
The new API does nothing that cloud sync does not want: bookmarks, obsmarkers,
prefetch, etc. Wrappers to disable features are removed.
This solves a "lagged master" issue where selectivepull adds `-B master` to
pull extra commits but cloud sync cannot hide them without narrow-heads. Now
cloud sync just does not pull the extra commits.
Reviewed By: sfilipco
Differential Revision: D20808884
fbshipit-source-id: 0e60d96f6bbb9d4ce02c04e8851fc6bda442c764
Summary:
With selective pull (now in core) enabled and narrow-heads disabled,
there is another way to cause lagged master.
Reviewed By: sfilipco
Differential Revision: D20808885
fbshipit-source-id: ebaed0e203f2f9f981bf141ce6c82af33710ba53
Summary: This makes the upcoming change easier to verify.
Reviewed By: sfilipco
Differential Revision: D20808883
fbshipit-source-id: 5563601125ef5c961785f7275fd82fc3fefe53ff
Summary:
This makes it possible to do things like `hg up remote/foo` without having to
`hg pull -B foo` first.
Reviewed By: DurhamG
Differential Revision: D20531122
fbshipit-source-id: e95b2f0a49e4b815c136450d1f352a7973cb72ed
Summary:
The new `repo.pull` API aims to be tech-debt free. It does:
- Pull nothing instead of everything if nothing is specified.
- Update remote names that are explicitly specified, not everything the server
has.
- Do not update local bookmarks.
The direct motivation is to implement autopull `remote/foo` behavior while not relying on the pull command.
Reviewed By: DurhamG
Differential Revision: D20531119
fbshipit-source-id: 80c3bdd5556126d81af099a74f1345ecc94904b7
Summary: Debugging an issue where watchman returns a state error during histedit.
Reviewed By: quark-zju
Differential Revision: D20785858
fbshipit-source-id: 5baf762d1a5588573df9d01c63a24e751e04a811
Summary:
During the roll-out of commitcloud remotebookmarks sync, some clients may have it enabled, and others may have it disabled.
This can result in some clients having an empty set of remotebookmarks in their sync state for a version which actually
does have remotenames in the cloud workspace.
This becomes a problem when those clients start syncing remotebookmarks, for two reasons:
* They are unable to correctly apply the new cloud remotebookmarks, as they do not have the previous state with which to break ties, and the tie-breaking code doesn't work correctly if the old cloud remotebookmark is `None`.
* When they try to send the remotebookmarks delta to the server, they don't have the old state, and so compute the delta incorrectly. This results in `Duplicate entry for key` errors in the service.
We can handle this as follows:
* When syncing remote bookmarks from the cloud, ensure we correctly apply the remote bookmark updates, even if the old cloud remotebookmark is `None`.
* If the local repo is up-to-date with respect to the workspace, but the last sync state had no remote bookmarks recorded, sync the remote bookmarks again. This may involve pulling some more commits if the cloud remote bookmarks are ahead of the local remote bookmarks. If there truly were no remote bookmarks then this will be a no-op.
Reviewed By: quark-zju
Differential Revision: D20792360
fbshipit-source-id: cd1ed371d8d5b1be2767c8a8d4836ea870a4467b
Summary: Add a hint that points to customization and troubleshooting guides for the new graph renderer.
Reviewed By: xavierd
Differential Revision: D20763338
fbshipit-source-id: ee6d2464ae5955f0f0bf52d1994adfa2b74b3367
Summary:
This demonstrates that both the legacy extension and the new implementation can
co-exist, and we can enable/disable the new extension.
Reviewed By: DurhamG
Differential Revision: D20677443
fbshipit-source-id: 10896023f536984645371d557c3ad20daa8526dd
Summary:
In the legacy lfs extension, LFS blobs were stored as loosefiles on disk, and
as we saw with loosefiles for remotefilelog, they can incur a significant
overhead to maintain. Due to LFS blobs being large by definition, the number of
loose LFS blobs should be reasonable for repack to walk over all of them to
chose which one to throw away.
A different approach would be to simply store the blobs in an on-disk format
that allows automatic size management, and simple indexing. That format is an
IndexedLog. This of course doesn't come without drawbacks, the main one being
that the IndexedLog API mandate that the full blob is present on insertion,
preventing streaming writes to it, the solution is to simply chunk the blobs
before writing them to it. While proper streaming is not done just yet, the
storage format no longer prevent it from being implemented.
Reviewed By: DurhamG
Differential Revision: D20633783
fbshipit-source-id: 37a88331e747cf22511aa348da2d30edfa481a60
Summary:
Some tests fail because `hg init` sets the wrong initial store requirements and
then perform a narrow-head migration down, which prints extra messages. Fix them
by making sure the initial store requirements are the same as what the migration
code path expects.
Reviewed By: simpkins
Differential Revision: D20698637
fbshipit-source-id: 1422a4ea78222617d0e3f9631ad883d5a3fe6bb7
Summary:
One of the main drawback of the current version of repack is that it writes
back the data to a packfile, making it hard to change file format. Currently, 2
file format changes are ongoing: moving away from packfiles entirely, and
moving from having LFS pointers stored in the packfiles, to a separate storage.
While an ad-hoc solution could be designed for this purpose, repack can
fullfill this goal easily by simply writing to the ContentStore, the
configuration of the ContentStore will then decide where this data will
be written into.
The main drawback of this code is the unfortunate added duplication of code.
I'm sure there is a way to avoid it by having new traits, I decided against it
for now from a code readability point of view.
Reviewed By: DurhamG
Differential Revision: D20567118
fbshipit-source-id: d67282dae31db93739e50f8cc64f9ecce92d2d30
Summary:
The hgcache will soon contain an LFS subdirectory, this is uninteresting for
most of the tests, let's change them a bit so they only look at the packs
subdirectory.
With this, enabling remotefilelog.useruststore only has 2 failures. One due a
difference in handling corrupt data, with the ruststore being more explicit
that some data is missing instead of a generic "stream ended unexpectedly". And
the other due to some ordering difference when dealing with LFS data. The
latter will go away with the new LFS implementation.
Reviewed By: DurhamG
Differential Revision: D20543146
fbshipit-source-id: 09c76cacfb4687fd699b82cdf5057665ac6bd521
Summary:
This enforces certain selective pull logic in core. Namely, rewrite `pull -r X`
to `pull -r X -B master`.
Unlike selectivepull in remotenames, `pull` (pulls everything) won't be
rewritten to `pull -B master` (which pulls less commits and names).
Therefore this change always adds more commits to pull, and therefore should not
break existing users. Eventually we want the "not pulling everything" behavior,
but right now this just fixes `pull -r X` to also update important remote names.
Reviewed By: markbt
Differential Revision: D20531121
fbshipit-source-id: af457b5ddb1265b61956eb2ee6afb7b7208293e0
Summary:
This makes it possible to use template like `{remotenames}` or revset like
`remotenames()` without enabling the remotename extension.
Rarely used revsets like `upstream()` and `pushed()` are not moved.
Reviewed By: markbt
Differential Revision: D20529360
fbshipit-source-id: ea95b3324f974e112909cdd79ce662940a4f9b7c
Summary:
This makes it possible to resolve remotenames without enabling the remotenames
extension.
The config check `if repo.ui.configbool("remotenames", "bookmarks")` is dropped
intentionally as we only use remotenames for bookmarks, not named branches.
Since this only enables resolving more names, without disabling or changing
other features, and the remotename namespace priority is lower than local
bookmarks (ex. if a local `master` exists, then `master` will be using the
local bookmark, not the hoisted remote name), it should not cause breaking
changes.
Reviewed By: markbt
Differential Revision: D20529359
fbshipit-source-id: 4126faee1bb7f43ba547fab05dd6197b2e65c1fc
Summary:
This moves part of remotenames that provides the `repo._remotenames` object to
core. It should not change behaviors but merely makes `repo._remotenames`
available in core.
Reviewed By: markbt
Differential Revision: D20529358
fbshipit-source-id: 11c8538a0190101b09a4cb082018e73643a257e2
Summary:
This makes it so `hg status A` won't complain about race conditions about file
`B`. As we're here, the detector logic was also moved to the filesystem layer.
Reviewed By: DurhamG
Differential Revision: D20568151
fbshipit-source-id: 713e3775a14674fd170df391977d42d9dee0f718
Summary: For LFS blobs, these can be obtained very easily by querying the ContentStore.
Reviewed By: DurhamG
Differential Revision: D20504235
fbshipit-source-id: 937ef20184d6524b1355565f9ab81e40b56d7ab0
