Summary:
When syncing a commit cloud repo, if the user has put a bookmark on a public
commit that we don't have locally, also pull that public commit into the repo
so that we can put the bookmark on it.
Reviewed By: quark-zju
Differential Revision: D12815471
fbshipit-source-id: 080038e4e239170cad994ff4ab9326d787d1c0fa
Summary:
If you put a bookmarks on a public commit that one of your other synced
repos doesn't have, it will delete the bookmark when it syncs. This deletion
is then propagated to all your other synced repos. This appears to the user
like the bookmark just vanishing.
Reviewed By: quark-zju
Differential Revision: D12815470
fbshipit-source-id: 802f85433b9ad15db3fb9e82e1222224eff4ca88
Summary:
The `VLQEncode` and `VLQDecode` traits erroneously expected the (automatic)
`Sized` marker trait for `Read` and `Write`. This meant they couldn't be used
for trait object `Read`s or `Write`s without jumping through hoops or extra
`mut` keywords.
By not requiring `Sized` we can remove those workarounds.
Reviewed By: quark-zju
Differential Revision: D12816459
fbshipit-source-id: 16353e8fefff5738bd24a9f41c9d7d250aea56fd
Summary:
Suggested by jsgf, use Condvar to emulate the "blocking" behavior so we do not
need to hold MutexGuard for long. This removes most unsafe Rust and also avoids
leaking Mutex even if the Python world forgets to call `release`.
The only remaining "unsafe" is to bypass a rust-cpython API restriction that is
over strict in this use-case.
Reviewed By: markbt
Differential Revision: D11729852
fbshipit-source-id: 9c914f0769e6903e390982c7aa423bb7e3ae2742
Summary: It includes encoding and python path information that could be interesting sometimes.
Reviewed By: markbt
Differential Revision: D12813630
fbshipit-source-id: 679ae45a2df5d710651009cd71c85e31bbe578c2
Summary:
All `hg serve` processes on the server have `hg serve --stdio`, which is not
that useful about what it's doing.
Change it to include wireproto command, ex.
`hg serve (fbsource getfiles client-hostname)`
Reviewed By: markbt
Differential Revision: D10476292
fbshipit-source-id: ce215800d9422995905357d4d5bd79ca5f1d5337
Summary:
Introduce a new template config option `amend.messagetemplate`, which, when
set, is applied to the commit message when amend is run with the `-m` option.
The template is provided with the old message, as `oldmessage` as well as the
message provided on the amend command line, as `message`. This can be
configured so that the amend message only overrides part of the old message.
Reviewed By: quark-zju
Differential Revision: D10857454
fbshipit-source-id: 6eb6f33624fae32fc7a344769e39f5c7a78a3604
Summary:
The `truncate` tool isn't availble on OSX, so include our own in the test
suite.
Reviewed By: DurhamG
Differential Revision: D12815613
fbshipit-source-id: 510b2936f07c5193671baaeaec6620872c3ec982
Summary:
`hg debugcolor --style --color=no` crashes as the list of styles is empty. Just
print nothing in that case.
Reviewed By: quark-zju
Differential Revision: D11910780
fbshipit-source-id: bfc29e7e5190b5fede7950874ac7a88be3435b12
Summary:
Add support for colors specified as hex strings (#rgb or #rrggbb, like in CSS),
rendering them if the terminal supports truecolor mode.
True color support can be detected by the `COLORTERM` environment variable
being set to `truecolor` or `24bit` (currently VTE, Konsole and iTerm2 do this).
It can also be enabled by setting `HGCOLORS=16777216`.
Reviewed By: quark-zju
Differential Revision: D11353291
fbshipit-source-id: 9b30df9c7de3bbaa686bc610addfa529775b73cc
Summary:
Add label annotations to the blame template indicating how old the line is
(bucketed into various ranges). Define colors for these labels so that recent
lines are white, and older lines fade through yellow to black.
Reviewed By: phillco
Differential Revision: D10869068
fbshipit-source-id: 2b99c84c115c3f9e408468f52b5754ff820fcec5
Summary:
Make the space for Phabricator diff numbers larger, and right-justify the
output. This makes it look better.
Reviewed By: phillco
Differential Revision: D10868646
fbshipit-source-id: 7cf50677560a15ef77cc3681063e902d8d9e7a18
Summary:
The directaccess extension could be smarter to avoid walking through public
commits when marking ancestors as visible.
Reported by simpkins.
Reviewed By: DurhamG
Differential Revision: D12814546
fbshipit-source-id: 712db5b77afbb5108b696e1721d15c26c3a51176
Summary:
If the rust pack stores are used to access truncated pack files, currently they
panic. Instead, return a proper error showing what's wrong.
Reviewed By: quark-zju
Differential Revision: D10868299
fbshipit-source-id: 57fe5ec1ee4ee2a7bb10d2d5c5ca7082dc34125d
Summary:
D10516852 added the name of the pack file that was being scanned to the repack
progress bar. Implement this in the Rust repacking code.
Reviewed By: quark-zju
Differential Revision: D10557731
fbshipit-source-id: de2f0cc4a40005422235c3bd19d6a78a38ea44f3
Summary:
The `configlist` function converts a config value to a list of strings.
I have thought about using pest to parse it. However, pest might return errors
(ex. `a,",b` does not parse due to missing end quote), while the original logic
can happily parse everything (`a,",b` gets parsed into `['a', '"', 'b']`).
The code might be simplified to make it more obvious that `unwrap()` cannot
panic. But it handles so many corner cases that I'd like to port as-is for
correctness.
Reviewed By: DurhamG
Differential Revision: D9323743
fbshipit-source-id: 5f8be562b7437260b7551d87d751424558d76e8f
Summary:
This makes tests closer to production setup and removes a bunch of "saved
backup bundle to ..." messages.
With D9236657, this should not hurt server-side performance.
Unfortunately a lot tests cannot be migrated easily, mostly because revision
numbers are used. They are left with a TODO.
Reviewed By: DurhamG
Differential Revision: D9237694
fbshipit-source-id: c993fce18f07aba09f6d70964e248af8d501575a
Summary:
The test infra does not handle "skip" state gracefully and treats skips as
"failure". That generated scary reports like hundreds of tests are failing.
Stop reporting skips to fix it.
An enivronment variable is added to get the old behavior.
Reviewed By: singhsrb
Differential Revision: D12808196
fbshipit-source-id: 2356a1d6fdfe1d2991d28368787c7d2b7b525b6b
Summary: This is just the result of running `./contrib/fix-code.py $(hg files .)`
Reviewed By: ikostia
Differential Revision: D10213075
fbshipit-source-id: 88577c9b9588a5b44fcf1fe6f0082815dfeb363a
Summary:
This was added to rHG but is potentially harmful in fbsource,
leading to overlapping watches (which are exponentially expensive rather
than linear) and this empty config may cause certain features and tunings
to be disabled if you happen to watch this subdir first.
Finally, in Eden, watchman will refuse to watch this location anyway
because it is not at the repo root.
Reviewed By: singhsrb
Differential Revision: D10857366
fbshipit-source-id: 0d63ac60c6c6ca655b0d2df43d566d497520f1c2
Summary:
When the progress extension is not configured, this global
is never assigned. This caused the eden integration tests to fail.
Reviewed By: phillco, quark-zju
Differential Revision: D12239141
fbshipit-source-id: 84b3bcafa6cf1e2becfcc05a212a880590c598db
Summary:
With the obsmarker copying feature, rebasing revs containing obsolete
relationship would result in the markers being copied correctly.
Reviewed By: phillco
Differential Revision: D7121486
fbshipit-source-id: a666ad65c2eccbfd26db813d4f792c66489ead8c
Summary:
When exporting hg commits to git, previously it would compute a set of
all nodes in the changelog, and all nodes in the git map, and figure out which
changelog nodes were missing. In a large repository, this is very expensive.
Instead, let's start at the heads and walk backwards. Usually we're doing an
incremental export, so this very quickly traverse all the missing nodes and
finishes. This saves 10+ seconds off gexport.
Reviewed By: markbt
Differential Revision: D10861851
fbshipit-source-id: c7c7f45d6e60e3ee5ffa27e2d3c5fb705b41b1c1
Summary:
When exporting a hg commit into a git commit we'd check if individual
objects existed before we actually wrote them into git. In the majority case the
object does not already exist, and for very large repositories with lots of pack
files checking this is quite expensive.
Instead, let's just write the blob into the store. In the unlikely case that
the blob already existed, it will get de-duped during repack. This saves us
50% of time spent in some cases.
Reviewed By: markbt
Differential Revision: D10861852
fbshipit-source-id: 26718bd2e2cf40099ccf5d86e68607cd3dc9dc5a
Summary:
When doing a git import, it would load the entire git tree for the
commit into memory at once. In a large repository this can be very expensive,
especially if there are a lot of pack files.
Let's change the structure to dynamically load trees as they're requested. This
makes it O(changes imported) instead of O(trees in master).
Reviewed By: markbt
Differential Revision: D10858958
fbshipit-source-id: 1550acbd409f8b507339a2f123422ac0fbd79215
Summary:
Add templating for the program name. This maps:
* `prog@` -> `hg`
* `Product@` -> `Mercurial`
* `LongProduct@` -> `Mercurial Distributed SCM`
It also adds `:prog:command` as an alias for `:hg:command` in the help text definition.
Reviewed By: mitrandir77
Differential Revision: D10461874
fbshipit-source-id: 7006fc9c41ede6b16d9a1a56ed1c99979a5f2f7e
Summary:
If a corrupt pack file is encountered while marking the ledger for repack,
handle the failure.
Don't immediately delete the pack files. Keep them around as we may be able
to repack some of the non-corrupt contents (particularly when the file has
been truncated).
Once repack has completed, revisit the corrupt packs that we found. For shared
packs, delete them. For local packs, rename them. They are the only source of
the data, and we may be able to recover more data manually.
Reviewed By: DurhamG
Differential Revision: D10527544
fbshipit-source-id: f228fb4de3ff016a1c9035823bfa1d6b7767cdcb
Summary:
The incremental repack implementation omits repacking local data - it was
recently added for full repack, but not incremental repack. Add it to
incremental repack.
We also don't run `_deletebigpacks` for non-shared data, as that data is
only stored locally.
Reviewed By: DurhamG
Differential Revision: D10525957
fbshipit-source-id: 012d7e8d455ac607773fc7013dcc4df0881665e8
Summary:
It's not clear from the current progress bars exactly what is being repacked.
Updated them to say `shared`/`local` `files`/`trees` `data`/`history`.
Reviewed By: DurhamG
Differential Revision: D10518040
fbshipit-source-id: 80e2f2d1b0d3dad3fbc0626d68d56349bbddb6cf
Summary:
For progress bars with the item display enabled, additionally show which
location we are scanning when scanning locations for things to repack.
Reviewed By: DurhamG
Differential Revision: D10516852
fbshipit-source-id: 844c68e02f7c1599db260dfc861fd320009ebc1f
Summary:
Loose files don't contain the original filename inside them, but rather the
directory name is based on the sha1 hash of the filename. This means that
given a remotefilelog data file, we can't find out the name of the file that
it contains.
Repack needs to know this (plus it's also useful for debug purposes), so add
an additional file in the directory, `filename`, which contains the original
filename of all the data files in the directory.
It follows that `sha1(read(filename)) == basename(dirname(filename))`
Reviewed By: DurhamG
Differential Revision: D10516851
fbshipit-source-id: aeeb1a116e0d50a134c274c3bb31c7c26aa8015c
Summary:
The basestore resolvefilenames method is used to do a reverse lookup from
filename sha to filename. Sadly this information isn't stored anywhere, so we
must search through the changelog and manifest for it.
The manifest and full changelog is too large to search in large repos,
especially when some files may not even exist there. Only search draft commits
and the last 250,000 commits in the changelog. If we don't find it there, we
give up. In this case, repack will leave the file loose.
Reviewed By: DurhamG
Differential Revision: D10516853
fbshipit-source-id: 5e0e60d47b18e34ef9d692524e29b13392da8952
Summary:
Rather than just showing an empty screen, tell the user what is going on. We
don't really know how long this will take, or how much progress is being made,
so just use a spinner.
Reviewed By: DurhamG
Differential Revision: D10516854
fbshipit-source-id: fc2b4e321ef12501879dc35a6be42010786577d4
Summary: D10435279 somehow landed with a green test run, but I suspect it broke this.
Reviewed By: DurhamG, quark-zju
Differential Revision: D10863085
fbshipit-source-id: 3f4e95c7838c39f5801430356b72901d70086173
Summary:
tweakdefaults renamed core hg's `grep` to `histgrep`, and added a `hg grep` that behaves more like `git grep`, searching the working copy. This diff folds those changes into core.
The config changes from
```
[tweakdefaults]
allowfullrepohistgrep = False
```
to
```
[histgrep]
allowfullrepogrep = False
```
Reviewed By: quark-zju
Differential Revision: D10435279
fbshipit-source-id: ad3d1da5824511a612111715e46119d70066050f
Summary:
One thing that makes dealing with merge conflicts difficult at Facebook is that it can be tough to know *why* you have merge conflicts.
Because rebase processes one commit at a time, it's clear which of *your* commits is the problem, but finding the "other" commit is surprisingly hard. Often we rebase onto `master`, and in a monorepo, `master` is often a random commit that has no relationship to your code at all.
This diff attempts to improve the situation a bit by listing all of the commits between the common ancestor and the destination commit that modified the file. The user can then identify which are likely culprits:
```
warning: 2 conflicts while merging b! (edit, then use 'hg resolve --mark')
3 commits might've introduced this conflict:
- [0942ca9aff3d] random commit 1
- [3ebd0a462491] foo bar biz
- [3e5843b4b236] blah blah blah
```
When the destination is public, this approach requires one loose file download (~0.5s?) per conflicted file (this pulls in the full filectx history DAG, so further downloads aren't needed), which is likely acceptable as it only runs on conflicts, and provides value to the user. But it's also configurable for users performing massive codemods.
I'll add metrics to gather the average number if matched commits and the time taken to generate.
This doesn't put this information into the conflict markers, so a lot of people (Nuclide users or the default `editmerge` users) won't see it. We need to think creatively about how to expose it to them.
The ideal solution would tell you which commits edited the actual conflicted section(s), not just those that touched the file.
This requires fast remotefilelog downloads (cc @[100000771202578:Arun] :)). Once we have those, we can construct a local `linelog` of the commits involved, and used this to identify precisely which commits edited the conflicted sections of the file.
Reviewed By: quark-zju
Differential Revision: D9816270
fbshipit-source-id: 04e08dea7a9429eaeab0d40310cd34355104bb74
Summary:
Normally pushbackup should not take the repo lock. To debug when this does
occur in the background, add a debugstacktrace for lock aquisition when
infinitepushbackup.bgdebuglocks is set.
Reviewed By: quark-zju
Differential Revision: D10508808
fbshipit-source-id: 3cb2c155bac88751122111d91bdc1f51b381f7ff
Summary:
Use the workaround utility added by the previous diff.
This removes the last cause of deadlock to my knowledge. Hopefully the code is
now solid enough that deadlock won't ever happen.
Reviewed By: markbt
Differential Revision: D10850512
fbshipit-source-id: f1953c9fbf3e69b65f42d421c2c0c9af5dbe99f6
Summary:
The [bug 29988](https://bugs.python.org/issue29988) is, when Ctrl+C (or other
signal) interrupts a program between certain Python bytecode instructions,
`__exit__` might be skipped incorrectly.
A single signal can only skip a single `__exit__`. Therefore it can be
worked around by using a list of `with`s, like:
with c, c, c, c, c:
....
Make `c.__enter__` and `__exit__` do the real `__enter__` and `__exit__` at
most once. To use the bug to skip all 5 `__exit__`s, 5 signals need to be
delivered at 5 tiny windows, which is unlikely to happen practically. Besides,
we can increase the count of `c`s to become more confident.
Note this has to be implemented natively since pure Python code cannot
have a reliable way to record whether `__exit__` was called or not:
self._obj.__exit__(...)
# Insert SIGINT here
self._exit_called = True
The inner object has to be native too to make `__exit__` atomic. Currently,
it's restricted to only the `Condition` object.
Reviewed By: markbt
Differential Revision: D10850510
fbshipit-source-id: 5c523a7bce568509641f8870d7ea381c0a99975c
Summary:
The less Python instructions in the `__exit__` or `finally` block, the less
risk we have with SIGINT handling.
The old `ui._write` code path has 8 Python instructions before reaching
`release()`, `suspend.__exit__` has more.
```
Disassembly of ui._write, finally block:
844 130 LOAD_FAST 3 (suspended)
133 POP_JUMP_IF_FALSE 149
845 136 LOAD_GLOBAL 0 (progress)
139 LOAD_ATTR 11 (_suspendfinish)
142 CALL_FUNCTION 0
145 POP_TOP
146 JUMP_FORWARD 0 (to 149)
>> 149 END_FINALLY
Disassembly of progress._suspendfinish:
565 0 LOAD_GLOBAL 0 (_engine)
3 LOAD_ATTR 1 (_cond)
6 LOAD_ATTR 2 (release)
9 CALL_FUNCTION 0
12 POP_TOP
13 LOAD_CONST 0 (None)
16 RETURN_VALUE
Disassembly of progress.suspend.__exit__:
576 0 LOAD_FAST 0 (self)
3 LOAD_ATTR 0 (_suspended)
6 POP_JUMP_IF_FALSE 19
577 9 LOAD_GLOBAL 1 (_suspendfinish)
12 CALL_FUNCTION 0
15 POP_TOP
16 JUMP_FORWARD 0 (to 19)
>> 19 LOAD_CONST 0 (None)
22 RETURN_VALUE
```
This diff changes it so `__exit__` is backed directly by the `Condition`
implementation, minimizing the Python instructions. In case `Condition`
is backed by the native Rust implementation, it is atomic and cannot
be interrupted by Python exceptions.
`util.nullcontextmanager` is rewritten to be more efficient.
Reviewed By: markbt
Differential Revision: D10843398
fbshipit-source-id: ba5f5d47b5b9948324a228778e3362531da87107
Summary:
The Rust implemenation has a smaller chance to have deadlock issues when
interruptted.
Reviewed By: markbt
Differential Revision: D10843400
fbshipit-source-id: af5614b9992577bde74cf54c5760d15d050aafbf
Summary:
This reduces the chance that SIGINT can cause deadlock.
A config option is added in case things go wrong.
Reviewed By: markbt
Differential Revision: D10843397
fbshipit-source-id: 49e61fd404e5bb8ba32f9e66ea7609c427d1f590
Summary:
Python 2's `threading.Condition` and `threading.RLock` implementation are in
pure Python. Part of `RLock.acquire` looks like (simplified):
def acquire(self, blocking=1):
me = _get_ident()
if self.__owner == me:
self.__count = self.__count + 1
return 1
rc = self.__block.acquire(blocking)
########## Here #########
if rc:
self.__owner = me
self.__count = 1
return rc
If an interruption (ex. SIGTERM) happens at "HERE". The lock would be in an
inconsistent state. And if some `finally` block, or `__exit__` in a context
manager tries to release the lock, it could deadlock.
Similar problems also apply to `release`, `_acquire_restore`, and
`_release_save`. Basically, `self.__owner`, `self.__count` and `self.__block`
(i.e. the real lock) cannot be guaranteed in a consistent state in pure Python
world, because interruption can happen before any Python bytecode instruction
(but not inside a single Python bytecode instruction).
Therefore the interruption-safe implementation cannot be done in pure Python.
Use Rust to rescue.
The added test `streetest-condint.py` has a high chance to reproduce the
deadlock issue with Python 2.
Python 3 has a native RLock implementation, which makes things better. The
"Condition" implementation is not native and I haven't checked whether it
is sound or not.
Unfortunately, as part of testing, I hit https://bugs.python.org/issue29988 and
confirmed from the Rust world. That is, `__exit__` is not guarnateed called (!!)
That means native implementations still have a chance to be wrong, and there is
no easy way to fix it. `streetest-condint.py` was then updated to expose the
issue more easily.
The implementation is better than Python 2 stdlib, though.
Reviewed By: markbt
Differential Revision: D10517920
fbshipit-source-id: 394c9050c512ce2a0f9743c28ccfafe0f560141a
Summary: 2 seconds can be too short for some tests.
Reviewed By: phillco
Differential Revision: D10856056
fbshipit-source-id: 86df0805390784d764045a7989978cd7949ca51e
Summary:
Currently it's just fixing copyright headers. I plan to make it also normalize
Cargo.toml and add a test-check for it.
Reviewed By: phillco
Differential Revision: D10213072
fbshipit-source-id: 38b7ba6d308bba3e13fe8db2eeb185c822838b78
Summary:
Adds the `grep.biggrepcorpus` option that links the repo to the appropriate
biggrep corpus to each of the repo specific configs that we maintain.
This allows us to know when a repo can be used with biggrep.
Use this option to automatically enable the use of biggrep when in an eden repo.
Reviewed By: quark-zju
Differential Revision: D10434568
fbshipit-source-id: a2c77d8c58b611f818d08725a6298dec1263bb8a
Summary:
Clean up the less helpful documents.
- GeneralDelta: Mostly about migration. We're already migrated.
- RepositoryLayoutRequirements: Mostly about migration. We're already migrated.
- Revlog: Ancient. Not used in production.
- HttpCommandProtocol: Lack of content. Not really used in production.
- SshCommandProtocol: Lack of content.
Reviewed By: phillco
Differential Revision: D10287049
fbshipit-source-id: 54d2b00f146057a8a246c284043adc651db478d8
