Although businesses need planning and scheduling, the need varies from organization to organization. For some organizations, like consulting companies, this is very important, and they may want to track time spent on individual tasks, and have a greater need for short-term forecasting and precise time accounting. Other companies, like Facebook, do very little of this. Our own company performs very little scheduling or time-based planning, and what scheduling we do is coarse and high-level (see T4778 for some discussion).

Phabricator does not do a very good job of this right now, and all approaches involve a lot of manual work.

Yeah, policy rules are a little muddy here. We should probably:

It's just 8MB * headroom factor.

Something is calling arc svn-hook-pre-commit, but it's not any of that code. Do you have another hook?

This API is partly odd because I want to disable chunking into MySQL by default, but allow users to enable it relatively easily. That motivates the <4MB -> 4MB chunk-enabling threshold. We could hard-code the 8MB single-file threshold but I suspect the total number of custom storage engines in the wild is about 3 so I figured I'd wait until the next iteration to figure out where the API should go (I want to the config into the Files web UI, which would let us expose [ ] Enable chunk storage for this engine or whatever).

(8MB just stores all 1-chunk and 2-chunk files as single files, and then starts chuking as soon as we'd have 3 chunks.)

Ohhh. Set these options in your custom engine:

Hmm, I'm not sure. We use nginx on this server -- client_max_body_size is technically set to 128m, but 32m should be more than enough.

Not precisely related, but as of a day or so ago, at HEAD, file sizes are unlimited for all users if you have at least one storage engine capable of storing 4MB chunks. The documentation has been updated and should reflect the modern state of the world:

This feature didn't even exist in Phabricator until 2012 (see T228). For the entire time we were employed at Facebook (more or less, I guess you guys left a little later than me), no one complained about this or requested the ability to change the behavior. And the user who eventually complained is the #1 email hater of all time.

Can you walk me thorough the kind of abuse/misuse you're seeing (or anticipating)? We have quota infrastructure and could extend it to files, but there's currently no per-user component, and I'd like to see if we can come up with better approaches to handle specific abuse scenarios since quotas are a pretty blunt instrument.

We intentionally do not provide this capability from the web UI. For rationale, see:

Can you show me the output from this?

I reincarnated the remaining work here as T7589.

I'm going to re-express this as separate subtasks of T7572 since the remaining behaviors have different blockers.

I'm just going to merge this up into T7569, this doesn't have much of specific interest outside that task.

There's no clear way forward here.