There's a new status panel in Config → Notification Servers. I'm consolidating cluster status information there.

We could maybe git ls-tree -r -d -- <tree> and then parse that. Still a lot of stuff, but somewhat less than the other approaches -- it only takes about 20ms to generate for phabricator/. If that output more than 5K paths or whatever we could give up and fall back to an unfolded list.

A big chunk of this is finally in production and seems to be working, which I'm thrilled about.

This is happening generally as part of T10751. I'm just going to close this out since I don't think it's useful as a separate task.

The logs themselves are a bug that's been around for a while, but I think they're from a race condition that I believed only caused things to log messages with no ill effects.

It looks like the DELETE statements can not be expressed in a way which doesn't upset the "unsafeness detector", even when explicitly ordered by primary key. I think this is the relevant MySQL issue:

Here's the section that's intended to explain it. This applies to Mercurial, too (in theory) which is why we don't explicitly mention git fetch.

Alternatively it seems like we can switch to MIXED mode and recommend that, but some installs probably won't be able to and I'm not sure what the tradeoffs are.

It should be fixed in HEAD, it just only regenerates once every 24 hours or something I think.

Should be fixed in HEAD of master. Thanks for the report!

The staging repository allows you to git fetch the change to the build server (which is easier and more reliable), instead of using arc patch.

The diagnostically useful information from the trace is that this:

In https://<your.install.com>/config/history/, is there a configuration change of any kind shortly before 17:19 UTC?

For design reference, here's the GitHub version of this mail (each comment arrives in a separate mail):

Why are you renaming columns?

I slightly reduced the amount of header magic, and the notification stuff is now cluster-ready (in theory, at least). I'm planning to get notifications, web nodes, and databases redundant in production today, and maybe repositories/daemons if nothing else comes up. No issues with repo bookkeeping so far but even if it's smooth sailing it needs a fair bit of UI work, and same with the daemons.

rCOREf9b858d57460 gives web nodes sudo access to svnserve when they're proxying SSH connections.

(Per T10799, T6878 is the underlying issue with why they don't import, but it's currently never materially useful to import them so this hasn't been a priority to fix. Empirically, they do not import on this install but builds work fine -- except see also T10667 for a weird special case mostly unique to this install.)

Staging is required (well, not strictly required, but strongly recommended) to setup CI.

Here's how I modified the configuration on this host (secure.phabricator.com) to account for this change.

I can not reproduce this issue by following your reproduction steps. Here's what I see on this install:

I've marked D15705 as fixing this, since it makes our interpretation of the path unambiguous: we would no longer interpret /ws/ as a request for namespace "ws".

Sorry about breaking this -- there are a lot of large changes going in this week related to T10751, so master might be a little less stable than usual until the dust settles there.

This should now be fixed in HEAD.

This report does not include reproduction steps. See Providing Reproduction Steps for help.

Upgrade Phabricator. This is fixed in HEAD.

This should be fixed in HEAD of master. Thanks for the report, let us know if you run into anything else.

Not 100% sure that's a fix, but I was able to reproduce something that looked similar and that appeared to fix it locally.

You can put lines=30 or similar after the triple backticks in the header:

(You may need to censor Authorization header bodies.)

What does GIT_CURL_VERBOSE=1 GIT_TRACE=1 look like for GitHub in your environment?

We need a good "Ph" currency name before I can really get maximally excited about it.

Since Windows tends to languish near the bottom of the priority list and I'm fairly confident this patch is fine, I'll accept it upstream if you use it for a couple days and nothing explodes and want to submit it.

I suspect that fix is safe and correct. It would be nice to kick the tires a little more before applying it and maybe try to dream up some test coverage, but it shouldn't have broader implications within the arc ecosystem.

T5953 might have some kind of options for this eventually with a longer timeline between polling checks (e.g., once an hour) but that's probably some ways away and probably wouldn't be a primary focus.

See T5834 for previous discussion.

this guy is pretty cool I like him 🐗

Per T6915, I'm likely to split the Phabricator side config into a list of services. If you run multiple servers, you list all of them and Phabricator can survive the loss of some subset gracefully. This should be easier for everyone to configure, too.