I stopped storage upgrade from running on out-of-service instances (rCOREe9f998b109c1) and upgraded db002 and repo002 to verify this change. We don't need to keep out-of-service schemata up to date, and this reduces the ongoing cost of out-of-service instances.

ab7dc13c67fd (Sun, Jul 5, 12:28 PM) is after the earlier patch 92b73fed6b2c (Fri, Jul 3, 10:59 AM). This is still an error with the migration.

I no-op'd the debian-start script and deployed db002 with the new changes (rCORE51d7570f5ddf) to verify it. I'm not going to restart db001 for the moment, since bringing it down is more disruptive and I only need confidence that the change is correct.

I've restarted the tier with a ~50% buffer pool configuration (4GB of 7.5GB) and 8GB swap (rCORE471d3a7acee1) and things seem to be holding stable. I'll pursue the other changes now.

Ubuntu also ships with some debian-sys-maint junk which runs huge, slow queries to check for problematic table data on every restart, which we should likely disable.

While I was writing this up, the host ran out of RAM and stopped working, so this is probably a memory management issue.

Some immediate observations:

Since your code is mostly PHP, you could possibly just run Diviner on things to get something for Google to hit. That might be way off (and we may not be able to parse/atomize things in the MW codebase correctly), but I could see it being at least as good as indexing the source itself. If someone searches for a class or function name, I think getting the definition is almost always way more useful than getting callsites -- maybe even if the hit is shell docs with a link to the definition. And in some future world where everyone has infinite time to generate wonderful stable docs, the doc hit seems clearly preferable.

...so I could get a better idea of how these fields are used. In this case, sadly. I didn't find much at all, though it probably isn't because of the robots.txt exclusion in diffusion.

https://secure.phabricator.com/book/phabflavor/article/please_please_please/

Generally, we prefer UI consistency and a simpler UI ruleset over preventing users from doing silly things.

The assumption is that you won't mix history.immutable (which compels arc not to mutate history) with rebasing (which mutates history): if you mutate history, we assume you're comfortable letting arc mutate history too. If you configure it as you have, you're locking us out of both commit messages (which we're forbidden from mutating) and commit/tree hashes (which may change after rebasing), so we don't have much to go on.

Mmmm, do you mean if I put "Differential Revision: DXXX" as the last line of the first commit of the branch, it'll be seen by arc and any subsequent arc diff will update the right review instead of creating a new one ?

Can you paste the exact error message you received?

Use arc which to understand what arc diff will do and why.

(The more-correct remedy is likely for the administrator to disable policy.allow-public or set the visibility of at least one space to "Public (No Login Required)" so logged-out users can see some objects.)

I just visited a site I don't have access to, so it should just say login or sign up.

Do you have one Space, which is available to "All Users" instead of "Public"?

This is now merged to master.

You can not delete tasks.

Also note that 20140218.passwords.2.prefix.sql is not idempotent, so re-running it if it already ran could break things.

The expectation is that 20140722.renameauth.php renamed provider classes, and 20140218.passwords.2.prefix.sql reformatted the passwords.

Can you give me an example of the kind of integration you're interested in? For example, what's a good query I can plug into Google or Bing and get a reasonable result in a codebase for?

See "Managing Storage Adjustments" in the documentation, which discusses this under "Troubleshooting":

I don't want to install it on cluster hosts, see T7785.

I believe this should now be fixed in HEAD. Please let us know if you encounter further issues.

I believe this should now be fixed in HEAD. Please let us know if you encounter further issues.

I decommissioned the old .org host. I'll give the old secure host another week or so since we did hit a couple minor config things where it was useful to double-check that there was a config change.

If you have a chance, can you pull a Services/Profile on this too? Round trip time on this install is <50ms.

If files had a directory structure on top of them instead, would that solve this problem?

Can you walk me through this? Why are you updating a revision after marking a bunch of things "Done", but not wanting the "Done" to publish?

I think this is covered, now?

Seems fixed.

This seems to be stable now, I don't immediately see any more ridiculously dumb slow stuff in the /feed/ profile. Remarkup handle fetches are still a bit loopy but that's a topic for another task.

This accurately reflects the user's action. We generally try to faithfully do what the user says, not what we think they mean. It is much more confusing if Phabricator ignores your edit without explanation than if it faithfully reflects an edit exactly as you made it, by accident.

We aren't interested in bringing this upstream.

I believe there are currently no "bad" versions of arc against HEAD which don't already tell users to upgrade -- some recent versions of arc had issues with recent versions of phabricator, but all recent versions of arc work correctly with HEAD. Although this presumably won't always hold, I think the miss rate here is so low that I can't imagine building anything in advance of the stuff connected to T5055.

There are no other steps to do.

This is probably fixed by rPd5e4d960.

Thanks.

Does it repro if you upgrade arc past rARC29839e8?

What hashes are arcanist and phabricator at?

This isn't something we're interested in pursuing in the upstream. You could add a Custom Field for it locally.

The exception is fixed; there's now a policy/filtering-related hang.

Here's the trace. I don't think this is a dupe.

I don’t want to change my project’s established conventions and clutter my git logs because arc wants to scatter droppings all over my commit messages.

do not necessarily reflect reality by the time it actually gets committed.

For example, the project might handle testing differently, and not want the ‘Test Plan’ section.

This behavior seems fairly expected/reasonable to me.

This is a very low priority for the upstream.

Please see Planning and Contributing Code. See also T8227.