Yeah, that claim assumes someone will arc diff some published commit sooner or later (i.e., run arc diff while on master with no local changes). While this wouldn't happen on a normal workflow or on purpose, I suspect it happens more-often-than-never.

I think that'll fix it. Thanks for the report!

I can't recall any reports of those issues on other installs, and we haven't experienced them ourselves. I don't think these issues are typical, frequent, or widespread.

Quick update here ahead of deployment tomorrow:

What are the specific things you want this feature for? Please describe the root problem you're facing. See Describing Root Problems for help.

Given how frequently ANSI characters and similar occur in build logs, this probably doesn't make sense until after we have support for binary data on the API (T5955).

Upstream builds have been in production for some time. There's always more work to be done, but I don't think there's anything actionable left here that isn't covered elswhere.

Is the outcome of this task likely to be select a source for a given project where source might be manual, or ldap, or something custom?

I don't intend to change that limit. I believe there is very little value in reviewing 1000+ file changes from the web UI, and that the 1K file limit is a reasonable one.

That commit is changing more than 1,000 files.

In T8612#163197, @paladox wrote:

What about per file diff viewing it would hide them by default but add an option to each file that says show diff.

Yes, this should eliminate the need to sync/cron/do anything.

I accidentally stumbled across the root cause for this and I think the fix is a one-liner, so it should work better after D15391.

Well, sort of. Projects don't get set correctly with explicit column.

column should be a PHID.

Yeah, this was mostly-intentional while resolving T9527 / T7661.

T8153 possibly also related (detect someone broke the resource and destroy it so it gets recreated).

We don't have a secret internal Phabricator full of juicy status updates: if we make progress, we'll update this task. See Planning for details.

We already have this.

See Contributing Feature Requests.

Yeah, they're hard to separate -- available rules depend on configuration, installed/uninstalled applications, extensions, and version, and individual rule behaviors may depend on things like the presence of dependencies on the system (for example, whether cowsay works, and which cows are available).

Yeah, the local help pages aren't generated by Diviner -- they're generally generated from the configured code at runtime.

It is very unusual for documentation to exist locally, as generating it currently requires building xhpast and doing setup on Diviner.

You may be able to call HTTPSFuture::setBlindlyTrustDomains(...) from preamble.php as a possible workaround, although you'll have to load some libraries first and this may interfere with error handling. Alternatively, you might be able to write an event listener which only calls this method as a side effect and does not listen for events (event listeners are allowed to run registration code early in the startup process).

Can you walk me through why can't you add the internal certificate to Phabricator's trusted CA chain?

I think that would be reasonable.

Thanks! Should be fixed by D15368.

• Provide some way to treat "too much output" as a categorical build failure, similar to how you might treat "excessive runtime" as a build failure.

Sounds like this has been resolved.

See script in T10350.

which svn client do you use ?

This should be fixed in HEAD. Thanks for the report!