found a corner case, fixed

I think that, after the hidden comment is loaded in its bulk, "some more comments" are loaded as context for the hidden comment 🤔 So I guess that extra loading is probably a feature and not a bug.

Wikimedia Foundation has this in production since years. I think it doesn't hurt.

Hi @keithzg (and any SVN hacker) do you like the new added Subversion support?

Probably not enough consensus for a mass edit. Best we can do is case-by-case fixes reading warn reports.

Any other test plan suggested? Current ones: delete simple milestone, delete project with milestone, delete a project with sub-projects, delete a sub-project, ecc.

One weird observation:

helping reviewers, adding comment on future export possibility

fix lint, happy review

it works!

This very patch got deployed on our rather active downstream instance 10 days ago. I have not heard complaints and I've seen tasks and task comments (replies) created via email, so I'm now pretty confident that it does what it should. Thus I'm going to merge it to reduce technical debt a bit more in Phorge.

add extra escape

OMG IT WORKS

Thanks. Seems good to me since trim($new) does not receive null so cannot create PHP 8.1 problems, since we already execute strlen($new) and mb_strlen($new) and that was not reporting errors in your updated install

@avivey: Would you like to give this another review, once you find some spare time? TIA!

Restore an empty line

I see the API maniphest.createtask is frozen, maybe this can also create tasks: https://we.phorge.it/conduit/method/maniphest.edit/

• APC: Change the setKeys $ttl parameter default to 0

This exception happens once $rule in the loop foreach ($this->getMarkupRules() as $rule) in PhutilRemarkupBlockRule::applyRules($text) becomes ProjectRemarkupRule. That's where it blows up.

Think I may have found what is causing this. We had a few repositories that auto download/sync from github. The user's key who connects to github was missing so the downloads were giving errors. I think this triggers a memory leak for the php process. Now that I've fixed the key issue no errors now appear and phorge looks to be happier, i.e. memory usage looks minimal all the time (i.e. php-fpm processes using ~100MBytes).
I'm going to keep monitoring for a few weeks.
Here's an example from the log:

(The Arguments have a supports feature for these cases - like https://we.phorge.it/source/arcanist/browse/master/src/workflow/ArcanistLintWorkflow.php$67 . Not sure what it actually does, but 🤷🏻‍♂️)

In D25823#22043, @avivey wrote:

What if the user used the svn checkout svn+ssh://phab@phorge.example.com/source/myrepo/trunk myRepoOnlyTrunk form - are we still able to find the right target when arc browse lol.txt? Is it a common use-case?

I will add a warning about --branch and better management

For testing, I deployed the latest revision of this proposed patch in our downstream instance and created a task via incoming plain text mail with attachments - seems to still work as expected so no obvious breakage (yet): https://phabricator.wikimedia.org/T377859

Fix typo

mimemailparser: Check that PHP mailparse extension is installed