facebook/sapling
1
1
Fork 0
mirror of https://github.com/facebook/sapling.git synced 2024-10-04 22:07:44 +03:00
Code Issues Projects Releases Wiki Activity

Grammar fixes in organizational.md (#247)

Browse Source 
Summary: Pull Request resolved: https://github.com/facebook/sapling/pull/247

Reviewed By: sggutier

Differential Revision: D41502273

Pulled By: mzr

fbshipit-source-id: f267c7ee934982d02a34843ebfc65894f30de922
This commit is contained in:
Shish 2022-11-23 12:07:04 -08:00 committed by Facebook GitHub Bot
parent f243f226c9
commit 923291eed8
1 changed files with 1 additions and 1 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

2
website/docs/scale/organizational.md
View File

@ -50,6 +50,6 @@ Hash scheme changes, while rare, required the additional step of maintaining a m
Having real-time metrics on source control commands is critical for maintaining and improving the source control experience within Meta. Internally, we upload a wide variety of metrics for every Sapling command that is run, from command duration, to time waiting on other services, to number of files changed, network throughput, error traces, and more. This lets us not only keep an eye on long-term performance and reliability trends, but enables us to see the impact of current rollouts on performance and catch regressions before they affect everyone.
The metrics are also useful for debugging individual developer issues. If an engineer comes to us saying a given command failed yesterday, we’re able to look at the log and see exactly what Sapling commands ran around that time, where the commands spent there time, and how they exited. By combining the logs with Commit Cloud, the internal service that backups every commit as they are made, we’re often able to reproduce the exact situation the engineer experienced, without needing further information from the engineer.
The metrics are also useful for debugging individual developer issues. If an engineer comes to us saying a given command failed yesterday, we’re able to look at the log and see exactly what Sapling commands ran around that time, where the commands spent their time, and how they exited. By combining the logs with Commit Cloud, the internal service that backs up every commit as it is made, we’re often able to reproduce the exact situation the engineer experienced, without needing further information from the engineer.
Note, none of this applies to the open source release. Neither metrics nor commits are uploaded from the open source Sapling builds. These logging and metrics tools are strictly internal to Meta.