@avivey to do now:

The repo is set to "host" right now, but it can also be set to "observe from" or "mirror to" another repo.

Interesting, and a little troubling if I understand it correctly; It means that the query ... WHERE dst = $a and type = $b and src = $c will be a full-table-read, but the equivalent query src = $c and type = $b and dst = $a will use the index to resolve quickly?

Are the keys actually different? Looks like they have the same fields in different order. Does this makes a difference in the implementation?

I'm pretty sure getValueForQuery() should return some value?

I have a problem with this statement:

CVE-2017-5223, CVE-2018-19296 and CVE-2020-36326:

CVE-2021-34551:
This one requires passing user-provided input as a filename to the "setLanguage" method; We don't call that method.

First pass, these one do not apply to us (and some of them do not apply to anyone at all):

(I've put a note in Dependencies for now)

I guess we could also try to cache the individual rendered code-blocks.

(and I made sure this new function isn't exported to the arc lib namespace)

extract to function

Yeah, it's probably not impossible to so safely - especially since people has been working on it for over a decade - but it's hard to do right. I know Wikipedia allows user-uploaded SVGs in some way, so maybe this is a solved problem.

I fixed arc test-traits in R12 (45f900a587).

Update: I've installed pygments (2.15.1), and it took about 3 seconds to render. It takes about 14 seconds here (with pygments 2.3.1).

mm, dumping this file in my dev env renders pretty much immediately; that's a good sign that it's the code blocks, because (1) pygments is known to be slow and (2) I don't have it installed.

"slow remarkup" often boils down to 1-2 inefficient regexp in a rule somewhere.

In D25051#15888, @valerio.bozzolan wrote:

I'm a little worried about this migration; Do we have garbage collector for this? it would be safer to let it run.

You are concerned for performance reasons because it doesn't limit the results. Right?

Looks good to me. @speck

Look into the "is creation xaction" - we had a similar diff recently about creating Revision from raw diff that had a similar behavior.

Also, maybe combine with the ArcanistXUnitTestResultParser.

So maybe rename the parser to JUnitTestResult, or something like that (If that's the right name for the format and if phpunit is using the same format)?

1. (Yes, arc liberate --clean. I'll also run it in Phorge).
2. I'll check it again, I refactored some things and maybe I broke that.

Yeah, in this one special place it doesn't matter; But that page already have a special body, so we can save even the extra click by putting the message right there...

But in Diffusion, that button is hidden behind a "Actions -> Manage" button, inside a screen that also has dozens of other admin actions. The clutter cost there is minimized.

In that case, we don't even need another button - just add a line to the "deleted message" that says something like "To completely remove the history from the database, contact your admin".

I feel that adding such a button would clutter the UI.
Users should generally "know" that in order to really delete things, they need to go to the admin, because they don't have the permissions anyway; And adding that just for the once-in-a-while that the admin needs this...

I don't think we actually allow "deleting" from the web ui, only hiding it (in the sense that the data is not removed from the database).

It also effects the PhabricatorCustomField::ROLE_APPLICATIONSEARCH condition, and possibly actually storing the data in some search-able table.
But try other roles - maybe it will work anyway.

move }

lint

Here's what it looks like with all the bells:

small fix

So after working on this for a day or so, and making much progress, I found that I already built this once 🤦‍♂️
https://secure.phabricator.com/D17004

I think we already did - @valerio.bozzolan ?

It's a Phacility server, managed at https://secure.phabricator.com/phurl/

I've looked down some of the links of this request, and it looks like the definition of "new user" should be install-specific, and open to interpretation.

I changed my mind again. No need for edges (short story is, getting the "color" property from the edge is annoying).

Yeah, I don't like the diviner page.
For other included 3rd parties, we often put a license file right next to the asset:

• https://we.phorge.it/source/phorge/browse/master/webroot/rsrc/externals/font/lato/LICENSE.txt
• https://we.phorge.it/source/phorge/browse/master/webroot/rsrc/externals/d3/LICENSE
• https://we.phorge.it/source/phorge/browse/master/externals/mimemailparser/LICENSE
• and, https://we.phorge.it/source/phorge/browse/master/externals/octicons/LICENSE which is not next to the actual content.