Summary:
Codicons don't have a good option for stack editing, let's make our own for now. Not the best thing in the world, but I think it's a slight improvement to using a codicon like `checklist`
{F952408652}
Reviewed By: quark-zju
Differential Revision: D45099438
fbshipit-source-id: d2f314aa0269676d7a6e1404a830cf7f2a4d308d
Summary: it has been enabled in prod for 5 months, let's enable it by default
Reviewed By: sggutier
Differential Revision: D45086467
fbshipit-source-id: 3b0df83105ad76b67f6e841e81cd7223b68e3e9b
Summary: Remove the last import cycle by extracting this util into a utils file.
Reviewed By: sggutier
Differential Revision: D45017252
fbshipit-source-id: 3455183a3239d0e486ddb1c383a8f476c55f507d
Summary:
Remove another import cycle from an atom used for previews. This is the only atom used in previews, and it kind of makes more sense alongside other similar operation-related atoms in serverAPIState.
Maybe later we'll move all these things to a new file just for everything operation-related, but I think it's ok in here for now.
Reviewed By: sggutier
Differential Revision: D45017251
fbshipit-source-id: 897583f5dc5d3d366f2a53ac0d4970121e7096b2
Summary: Remove one more import cycle by separating a component used in multiple places
Reviewed By: sggutier
Differential Revision: D45017253
fbshipit-source-id: 0190071a46da7b5d03e506c06855b0a60960ad67
Summary:
We had several long import cycle chains related to analytics & the Internal abstraction layer. A lot of our internal features use tracking, so they are both exported by Internal and also import Internal for analytics.
I think analytics is a sort of a client that a lot of different features will need. It'll be easier if we can import analytics without worrying about cycles. So here I add a way to access the global tracker off the window object, which requires no imports.
We set the global object when we construct the tracker at the top level. But based on import order, if you try to use the window.getTracker() at the top level, it's possible that it hasn't been set yet. So this API is technically nullable. In practice, these callsites don't use tracking at the top level so it shouldn't matter.
We only need to use this when it causes an import cycle. Otherwise, we get better support by just importing directly.
This is a bit annoying, but it's nice to eliminate a whole category of import cycles.
Reviewed By: quark-zju
Differential Revision: D45017257
fbshipit-source-id: c91c6b114ef67f656f845e291c926cab9047588e
Summary:
Remove another import cycle by moving this commitMessageTemplate atom to the CommitInfoState file.
This is the only place we're using this atom anyway, so it makes more sense here
Reviewed By: sggutier
Differential Revision: D45017255
fbshipit-source-id: 4fc67067a4f6a6a0aa1672afacba44699fd80a4f
Summary: Remove an import cycle by extracting the drawerState atom into its own file
Reviewed By: sggutier
Differential Revision: D45017254
fbshipit-source-id: db2487bc665be5520a07f165147554ac3e4becd1
Summary:
I noticed this warning when building the VS Code extension, we should update our import to silence this
{F948346674}
Reviewed By: sggutier
Differential Revision: D45017256
fbshipit-source-id: 76ad56284397a56132fa4209ea305febc31518ee
Summary:
[sl] fix compatibility with PEP 440
Our current versioning schema isn't compatible with PEP 440. Luckily, changing the last `-` to a `+` works.
Credit for the idea goes to ZhongRuoyu as mentioned in https://github.com/facebook/sapling/issues/598
Pull Request resolved: https://github.com/facebook/sapling/pull/606
Test Plan:
- Ran `sl --version` to verify that it outputted a sane format (got `Sapling 0.2.20230417-165855+6db1e950`)
- Verified that this was compliant with PEP 440: https://regex101.com/r/sv6aUZ/1
- Verified that this was compliant with Semver 2.0: https://regex101.com/r/RQsynA/1
- Also, verified that this was still compatible with Homebrew in a similar way to D42006425:
```
$ git --no-pager diff
diff --git a/Library/Homebrew/test/version_spec.rb b/Library/Homebrew/test/version_spec.rb
index 647fb5dcc..ac35b920a 100644
--- a/Library/Homebrew/test/version_spec.rb
+++ b/Library/Homebrew/test/version_spec.rb
@@ -841,6 +841,12 @@ describe Version do
.to be_detected_from("https://opam.ocaml.org/archives/easy-format.1.0.2+opam.tar.gz")
end
+ specify "sapling-better" do
+ expect(described_class.create("0.2.20230417-165855"))
+ .to be_detected_from("https://github.com/facebook/sapling/archive/refs/tags/0.2.20230417-165855+6db1e950.tar.gz")
+ end
+
+
specify "no extension version" do
expect(described_class.create("1.8.12"))
.to be_detected_from("https://waf.io/waf-1.8.12")
%
```
```
$ ./bin/brew tests --only version -d -v
Randomized with seed 48812
bundle exec parallel_rspec --nice -- -I /Users/sggutier/homebrew/Library/Homebrew/test --seed 48812 --color --require spec_helper --tag ~needs_linux --tag ~needs_network --tag ~needs_ci --tag ~needs_svn -- test/version_spec.rb test/version/parser_spec.rb
2 processes for 2 specs, ~ 1 spec per process
...................
.....................................................................................................................
Took 2 seconds
```
---
Stack created with [Sapling](https://sapling-scm.com). Best reviewed with [ReviewStack](https://reviewstack.dev/facebook/sapling/pull/606).
* __->__ https://github.com/facebook/sapling/issues/606
* https://github.com/facebook/sapling/issues/605
Reviewed By: zzl0
Differential Revision: D45072716
Pulled By: sggutier
fbshipit-source-id: 6fea731486e8b7ea4606a96b064dc3f724420649
Summary:
[sl] bump macOS python CI to 3.11.3
We still depend on pointing to the specific Python combination that GitHub CI and Homebrew have, which currently is 3.11.3.
Hashes were taken from d39875e212/Formula/python@3.11.rb
Pull Request resolved: https://github.com/facebook/sapling/pull/605
Test Plan:
Downloaded bottles from:
https://github.com/sggutier/sapling/actions/runs/4727040284https://github.com/sggutier/sapling/actions/runs/4727040323
and installed the arm64 version. Also, verified that the dumps from `otool -L` looked correct (they usually don't when there is some when building)
Dump from arm64 version:
```
$ otool -L sapling\ 8/0.2.20230417-165855+6db1e950/bin/sl && file sapling\ 8/0.2.20230417-165855+6db1e950/bin/sl
sapling 8/0.2.20230417-165855+6db1e950/bin/sl:
/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 1311.100.3)
/usr/lib/libiconv.2.dylib (compatibility version 7.0.0, current version 7.0.0)
/System/Library/Frameworks/Security.framework/Versions/A/Security (compatibility version 1.0.0, current version 60158.100.133)
/System/Library/Frameworks/CoreFoundation.framework/Versions/A/CoreFoundation (compatibility version 150.0.0, current version 1858.112.0)
@HOMEBREW_PREFIX@@/opt/openssl@1.1/lib/libssl.1.1.dylib (compatibility version 1.1.0, current version 1.1.0)
@HOMEBREW_PREFIX@@/opt/openssl@1.1/lib/libcrypto.1.1.dylib (compatibility version 1.1.0, current version 1.1.0)
/System/Library/Frameworks/SystemConfiguration.framework/Versions/A/SystemConfiguration (compatibility version 1.0.0, current version 1163.100.19)
/usr/lib/libz.1.dylib (compatibility version 1.0.0, current version 1.2.11)
@HOMEBREW_PREFIX@@/opt/python@3.11/Frameworks/Python.framework/Versions/3.11/Python (compatibility version 3.11.0, current version 3.11.0)
sapling 8/0.2.20230417-165855+6db1e950/bin/sl: Mach-O 64-bit executable arm64
```
Dump from x86 version:
```
$ otool -L sapling\ 9/0.2.20230417-165855+6db1e950/bin/sl && file sapling\ 9/0.2.20230417-165855+6db1e950/bin/sl
sapling 9/0.2.20230417-165855+6db1e950/bin/sl:
/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 1311.100.3)
/usr/lib/libiconv.2.dylib (compatibility version 7.0.0, current version 7.0.0)
/System/Library/Frameworks/Security.framework/Versions/A/Security (compatibility version 1.0.0, current version 60158.100.133)
/System/Library/Frameworks/CoreFoundation.framework/Versions/A/CoreFoundation (compatibility version 150.0.0, current version 1858.112.0)
@HOMEBREW_PREFIX@@/opt/openssl@1.1/lib/libssl.1.1.dylib (compatibility version 1.1.0, current version 1.1.0)
@HOMEBREW_PREFIX@@/opt/openssl@1.1/lib/libcrypto.1.1.dylib (compatibility version 1.1.0, current version 1.1.0)
/System/Library/Frameworks/SystemConfiguration.framework/Versions/A/SystemConfiguration (compatibility version 1.0.0, current version 1163.100.19)
/usr/lib/libz.1.dylib (compatibility version 1.0.0, current version 1.2.11)
@HOMEBREW_PREFIX@@/opt/python@3.11/Frameworks/Python.framework/Versions/3.11/Python (compatibility version 3.11.0, current version 3.11.0)
sapling 9/0.2.20230417-165855+6db1e950/bin/sl: Mach-O 64-bit executable x86_64
```
---
Stack created with [Sapling](https://sapling-scm.com). Best reviewed with [ReviewStack](https://reviewstack.dev/facebook/sapling/pull/605).
* https://github.com/facebook/sapling/issues/606
* __->__ https://github.com/facebook/sapling/issues/605
Reviewed By: zzl0
Differential Revision: D45072742
Pulled By: sggutier
fbshipit-source-id: 4ced2d609d9cf4098cd4bbea5d5df45659588ad8
Summary: Look at at all the lines of code we could delete!
Reviewed By: YousefSalama
Differential Revision: D45057185
fbshipit-source-id: c454a4bd70527460bf4a727aa3ebe57b3becab4d
Summary:
I didn't want to repeat myself too much so I'm introducing macro that will do
that for me.
Reviewed By: YousefSalama
Differential Revision: D45057186
fbshipit-source-id: 6e13a5a72c6ad463982611ce11a16f937dcd9386
Summary:
The add_recursive would try to access the parents from changesets table
even if they're not there yet (in some places we're racing to inster them to
both tables at the same time).
For that we need to:
* process changesets in reverse topological order
* check edges_map before trying to fetch parrents from legacy changesets table
* skip fetching parents if the parent will be processed in the same function call
Reviewed By: YousefSalama
Differential Revision: D45057189
fbshipit-source-id: 7906c610c7a4f8473647796e0c56962e074a035f
Summary:
`add_recursive` has problem when adding many changesets not present in the
legacy changesets table. This test showcases the problem, the next diffs will
attempt to fix it.
Reviewed By: YousefSalama
Differential Revision: D45057188
fbshipit-source-id: 56297b7e2d47c6ec65023e9782ac0e18012a4319
Summary: Those helped me to localize the source of errors. I might as well commmit them.
Reviewed By: YousefSalama
Differential Revision: D45057187
fbshipit-source-id: 694d9596dec030e65b0d29590068103fb1b70ca9
Summary:
**Context**
D37136735 introduced a new type called `ContentMetadataV2`, to include more information about a file. For example, if a file is binary.
We want to modify the file_info endpoint in SCS, so that users can directly query the metadata for a file.
**This diff**
Implement the modified version of file_info endpoint using the ContentMetadataV2
Reviewed By: markbt
Differential Revision: D43537343
fbshipit-source-id: 98554366a725636d4cd6989fb7e2d9b5fe29d5e4
Summary:
**Context**
D37136735 introduced a new type called `ContentMetadataV2`, to include more information about a file. For example, if a file is binary.
We want to modify the file_info endpoint in SCS, so that users can directly query the metadata for a file.
**This diff**
Modify Thrift data type, and the function signature for the endpoint
Reviewed By: markbt
Differential Revision: D43537344
fbshipit-source-id: 6076703f67923e0fa95676b0db812a75fb6c3650
Summary:
These have broken production as the behaviour was changed so that `--foo` would no longer be valid when it used to be.
The behaviour changed inadvertently when migrating these CLIs to clap 4.
Differential Revision: D45081836
fbshipit-source-id: ffa7a2a2b1c04c860082bb2770eaa2cde1e7519f
Summary:
Fixes some warnings about unused imports and struct fields when building on
Windows.
Reviewed By: MichaelCuevas
Differential Revision: D45061519
fbshipit-source-id: 322768bf4e0d2af47129bd8f5c376211ee98d0d8
Summary:
My goal is to decouple our inode layer, including EdenMount, from the
specific filesystem implementation. To that end, remove several FUSE
references from EdenMount's comments and variable names.
Reviewed By: kmancini
Differential Revision: D44737102
fbshipit-source-id: 9956cf818599d508a897b92936350f40207d4b40
Summary:
Small refactorings that don't have a particular theme. I'm working
towards removing FUSE- and PrjFS-isms from EdenMount and friends.
Reviewed By: kmancini
Differential Revision: D44728015
fbshipit-source-id: 328abae1043a48f440836b98f1a1ee20a1b091d1
Summary: I think I addressed this one already in D44187187 but forgot to remove the FIXME.
Reviewed By: evangrayk
Differential Revision: D45050467
fbshipit-source-id: eb408ae2a9e1ba873e7f28ec3ff1cb755a1d2560
Summary: Fixed the cont-builds command and updated the tests to actually work instead of just passing all the time
Reviewed By: skotchvail
Differential Revision: D44898873
fbshipit-source-id: dbbc7429942a2d400346004e13bf7ba3cb00476d
Summary:
On Windows most applications, including Windows Explorer, are not able to open symlinks if they have forward slashes (e.g., `eden/scm/Makefile`). Windows users creating symlinks will probably create symlinks with backward slashes instead because of this (e.g., `eden\scm\Makefile`). Analogously, symlinks with backward slashes will be of not use on POSIX systems.
This diff tries to alleviate this by making symlinks added to commits on Windows via `hg commit` usable everywhere else.
Reviewed By: zzl0
Differential Revision: D44358129
fbshipit-source-id: 2835652b62104e22f10cb422586fae9998db40ad
Summary:
Makes `hg diff` and `hg commit` work as one would expect on Windows. This is done by modifying some constants in `fscap.py`.
This change should not impact end users, as explained in previous diffs.
Reviewed By: muirdm
Differential Revision: D43741223
fbshipit-source-id: 203878f64c11364257cef4bb82395713456f3625
Summary: The working copy uses the VFS object for determining whether a file is a symlink or not. Previously this behavior was disabled as there was no support for symlinks at all when this was written.
Reviewed By: muirdm
Differential Revision: D44592907
fbshipit-source-id: 6b9041a5045a336292a2b641da30cf3ae22f441c
Summary:
I noticed when reading the EdenServer startup and shutdown logic that
we did not log the structured DaemonStop event on Windows. The ifdef
must have been vestigial, so remove it.
Reviewed By: xavierd
Differential Revision: D44699330
fbshipit-source-id: 529aa2b2933b1ef3b8337fa19c1b88b9033653ba
