Summary:
In Mercurial we're finding use cases for conditioning on buck vs
non-buck builds. For instance, in some cases we specify #[link] directives for
non-buck builds, but don't need to for buck builds
(https://fb.workplace.com/groups/rust.language/permalink/4568487309866515/). In
other cases we want to depend on internal buck libraries when building with
buck, and not otherwise.
Let's add a fb_buck_build cfg so other projects may distinguish the same.
Reviewed By: jsgf
Differential Revision: D24493974
fbshipit-source-id: 1d558cbe0ae01ab4a7b4b5d6d4be75bb8ab0f41a
Summary: This method is an override of its parent class, thus the need for the override.
Reviewed By: chadaustin
Differential Revision: D24657424
fbshipit-source-id: 5ce7200eeb4ef28fb51fabbe0ebb38ded51ae34e
Summary:
Dealing with non-owned path in futures is mind bending and can lead to use
after free fairly easily if not careful. It turns out that this code is
actually a bit buggy and in some cases will attempt to use a path that is
already freed. Since the callsite doesn't need to hold onto the paths, let's
just move them, which resolves the issuue.
Reviewed By: chadaustin
Differential Revision: D24657423
fbshipit-source-id: 47bbaccf18cd86e53860491e3cbfeadb4363499c
Summary:
The rage local config output was getting polluted by dynamic config.
Let's filter them out.
Reviewed By: farnz
Differential Revision: D24626564
fbshipit-source-id: df5ac04cd549595ecdccc0b2438d4e7c72b80e88
Summary: When I added `eden uptime`, I did not see that we already had `eden debug uptime`! Instead of having two, lets just use the one and remove it from debug. There seems to be a regression of the uptime I had implemented, so thats why I opted to use the implementation of the debug version.
Reviewed By: kmancini
Differential Revision: D24566844
fbshipit-source-id: d948a5303d475a543f51abbaea59f9c481dfeca2
Summary:
Previously, reading from SSH subprocesses did’t return on Python 3. bufsize=0
is default on Python 2, but not Python 3.
This is a backport of: 0fc8020ebe
Reviewed By: krallin
Differential Revision: D24652418
fbshipit-source-id: 1140c76b6f711bfe1726108bd4fe6948e6ee41a0
Summary:
We don't need an ifdef here as folly::kIsWindows works just as well. The astute
reader will notice that we now call isInodeRemembered while we weren't before.
On Windows, this will pretty much always return false as this can only return
true if the fuse refcount is positive. Since we don't keep track of a fuse
refcount on Windows, this is OK to do.
Reviewed By: genevievehelsel
Differential Revision: D24636432
fbshipit-source-id: c6db7c66f7eb27894cdd276a9368149ec8056cf4
Summary:
One of the unforseen effect of D24393690 (c5d631fd09) is that EdenFS was tied to the console
that ran `edenfsctl start`. As a result, killing that console would also kill
EdenFS, which is a bit unexpected.
Console in Windows are a bit complicated, and in theory, EdenFS could simply
call `FreeConsole` once it is started, but the side effect of this is that any
process started by EdenFS (say Mercurial), would create its own console as its
parent doesn't have one, specifying CREATE_NO_WINDOW when creating these would
lead to not having any output in the edenfs logs from Mercurial (D21820195 (223846d313))...
We could solve this if we could tell Windows to allocate a hidden console
window, but that API unfortunately doesn't exist.
So, the best we can do for now is to simply start EdenFS with the
CREATE_NO_WINDOW flag, this fixes the above issue, allows for the original
console to be killed without affecting EdenFS, but it brings another issue:
`eden start` no longer shows what is going on...
For now, this is the least worst solution, so we'll go with that. In the
future, we can imagine fixing EdenFS startup code to send its output to a pipe
that edenfsctl would read and print to its standard output.
Reviewed By: chadaustin
Differential Revision: D24607540
fbshipit-source-id: c18590052a96b7dd2938b589e92e808f38b5ef59
Summary: The more we remove, the easier it'll be to remove the last few problem cases.
Reviewed By: StanislavGlebik
Differential Revision: D24592052
fbshipit-source-id: de6371305991d54bf2802fd904850b49aeb11bbd
Summary:
This didn't matter much in practice because we've never pushrebased a rewritten
commit where one of the parents rewrites to nothing. Nevertheless I think it's
cleaner to return an error in this case
Reviewed By: ikostia
Differential Revision: D24621105
fbshipit-source-id: 8cf62efd28e0c9aed945f727b1872db6922cfeb3
Summary:
This stack has a goal of cleaning up how commits with no parents and
consequently merges are treated in CommitSyncer. At the moment it always uses current version
to rewrite them, and this is incorrect. See example below (here N means "new
commits" i.e. commits that weren't remapped yet but we need to remap them now)
```
large repo
O <- uses current version
|
O
|
O N
|/ |
O | <- uses old version
| N
| |
O N <- this commit should be rewritten with old version!
```
With current logic all N commits will use current version for remapping, but
this is incorrect, and instead "old version" should be used. The goal is to fix
it and make it so that backsyncer and x-repo sync job pick the correct version
to use for remapping.
-----
As it was noted in the previous diff we need a function that overrides a
version for a commit with no parents. We need this function because for a
commit with no parents CommitSyncer can't decide which mapping version to use
because, well, there are no parents which could have hinted about the version.
So let's add this function and cleanup unsafe_sync_commit_impl function to
apply version override only to a commit with no parents. If commit has parents then we'd verify that the version from parents matches the expected version.
In the next diffs I'll make it so that if a version for commit with no parents is not specified then
unsafe_sync_commit_impl fails rather than uses current version.
Reviewed By: ikostia
Differential Revision: D24617953
fbshipit-source-id: a68f837da9d90bb18034f628b7880482a2e548b7
Summary:
This adds some basic Scuba logging to commit sync logic in Mononoke. This can be disabled via a tunable.
Note: of course, the wrapping of logging functions would have been pretty cool to do in a macro, but I don't have time atm to figure it out, so have just code.
Reviewed By: StanislavGlebik
Differential Revision: D24571702
fbshipit-source-id: f8830fc675a2a62d2204671e86ab2c819372c5cc
Summary: This adds a `ScubaSampleBuilder` field to the `CommitSyncer` and ensures this field is instantiated with correct values (real vs discarding sample) depending on circumstances.
Reviewed By: StanislavGlebik
Differential Revision: D24539732
fbshipit-source-id: 37aedcff9aefcfcd6b740a0491ab35f9e5ce7c77
Summary:
Functionality of this function can be replaced with
unsafe_always_rewrite_sync_commit, so let's do that.
However in the next diff we'll need a function similar to
test_unsafe_sync_commit but with a slightly different semantics - instead of
forcing override for every commit we'll just force it for a commit with no
parents. Because of that let's not remove unsafe_sync_commit_impl function.
Reviewed By: ikostia
Differential Revision: D24616824
fbshipit-source-id: 6969145d98cd23604920a6b490bf7ffe47938c08
Summary:
Our integration tests do not have "test_version" version, they have only
"TEST_VERSION_NAME". This didn't make any difference because x-repo sync job
was always use the current version, but this is going to change soon. So let's
update the tests first
Reviewed By: krallin
Differential Revision: D24620364
fbshipit-source-id: 19416f6d6aba2d9c426efa545d18d4be458d3272
Summary: Those tests weren't really actionable, no one was paying attention to them and they recently started to report the whole job as failed even though the continue-on-error option was true. Just remove them.
Reviewed By: krallin
Differential Revision: D24645209
fbshipit-source-id: b21503a43db2afc82cccddc7fe6dd1daca2028dd
Summary:
Fixing test. I updated the serialization format in another stack and didn not
update the hash before I landed.
Reviewed By: lukaspiatkowski
Differential Revision: D24643831
fbshipit-source-id: 3ec888d99cbee0aa6d804740bebaf032dd28e2c9
Summary:
MySQL doesn't like that the idmap table is renamed to `inner`. For good reason,
inner is a keyword, best to rename it.
Reviewed By: ahornby
Differential Revision: D24568914
fbshipit-source-id: 7a3790e835931b29658c7652cc89069c6b9b5bab
Summary:
I avoided this function because it interacts in a weird ways with dependencies.
At this point I am no longer concerned about that and it can help us simplify
some code.
Looking ahead I think that we will refactor things into having fewer
dependencies.
Reviewed By: krallin
Differential Revision: D24555935
fbshipit-source-id: 994b25d90da491bb5cc593b6c33085790c4fb322
Summary:
The command reads the last SegmentedChangelog that was saved for a repository
and updates head to match a given bookmark (master).
Right now this is just a command that works on one repository. Follow up
changes will look at deployment options and handling multiple repositories.
Reviewed By: krallin
Differential Revision: D24516438
fbshipit-source-id: 8f04f9426c2f2d7748c5363d2dbdf9f3acb79ddd
Summary:
I initially saw the incremental build as something that would be run in places
that had IdMap and IdDag stored side by side in process. I am reconsidering
to use incremental build in the tailing process to keeps Segmented Changelog
artifacts up to date.
Since we update the IdMap before we update the IdDag, it is likely that we
will have runs that only update the IdMap and fail to update IdDags. This diff
adds a mechanism for the IdDag to catch up.
Reviewed By: krallin
Differential Revision: D24516440
fbshipit-source-id: 3a99248451d806ae20a0ba96199a34a8a35edaa4
Summary:
Nice to have things for debugging.
This isn't an exhaustive list of places that we could add context too. I'll
probably look to complete the list after the current changes are done.
Reviewed By: krallin
Differential Revision: D24516437
fbshipit-source-id: 7f29e7afde5a5918aea419181d786f48da9b8b14
Summary:
The general goal is to allign segmented changelog blobstore usage with the
general pattern in Mononoke.
Reviewed By: quark-zju
Differential Revision: D24605796
fbshipit-source-id: 808985609f74ebc45f3fcc57583e55f3af9bce1d
Summary: Change the default blobstore put behaviour to IfAbsent, so that all binaries apart from admin tools using MononokeApp::special_put_behaviour() pick up the change.
Reviewed By: farnz
Differential Revision: D24619663
fbshipit-source-id: 98439513b985d2cde88ef99e5eb177974e9db5c9
Summary:
Extend MononokeApp so admin apps can have a special default put behaviour (typically
overwrite) vs the soon to be new default of IfAbsent
Use it from the admin tools.
Reviewed By: farnz
Differential Revision: D24623094
fbshipit-source-id: 5709c68429f8e1de0535eec132998d20411fc0e6
Summary:
mitrandir77 pointed me to this field which is exactly what I want.
Leave alias handling in place for configerator, which has a different name.
Reviewed By: mitrandir77
Differential Revision: D24628323
fbshipit-source-id: ccd01e6314feefd8ab75e8052a0a8a98b3119691
Summary:
We want to be able to prefetch profiles on pull. That means we will need
to pick commits that will be good to prefetch for. This adds a flag --commits
that allows specifiying commits explicitly (mostly for testing), and a
flag `--predict-commits` which will pick good commits to prefetch for.
Reviewed By: genevievehelsel
Differential Revision: D23889882
fbshipit-source-id: 74e61c0c9d443ca396f326b0d547b9fc21a6364b
