Testing this a bit myself again, I discovered that actually this problem affects both Git and SVN, it just wasn't being noticed in my SVN testing because it doesn't go wrong if run from any subfolder. So for example in a checkout of rARC, running arc browse . in the root directory will pop one into the bogus path of, say, https://we.phorge.it/source/arcanist/browse/master/home/keithzg/Code/git/arcanist, but if I'm in my local ~/Code/git/arcanist/src/ then arc browse . pops open https://we.phorge.it/source/arcanist/browse/master/src as intended.

The only remaining issue I could find in retesting was that, when run on the root of a repo, apparently SVN exhibits the same behaviour as Git does in T15957; and furthermore in my testing actually Git also doesn't have that problem if arc browse . is run in a subfolder rather than the root of a repo. (It's just so much more common to be in the root of a Git repo, and so much less common to be in the true root of an SVN repo, that we didn't notice!)

Having the wiki's tree of contents on the side would indeed be pretty nice, I gotta say. This is especially the case on the landing pages of a given instance's wiki, at least until it inevitably sprawls to be gigantic ;)

Yeah I was also pretty sure Phab used mysqli? I have had to have it on all my installations, and the Phorge documentation still cites it. https://we.phorge.it/book/contrib/article/database/

I didn't notice anything amiss!

This would absolutely be useful in both the personal and professional Phorge instances I admin :)

Ah yeah that would 100% accomplish the ask here!

In D25823#22324, @valerio.bozzolan wrote:

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

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?

For what it's worth I've applied this to my personal instance which tracks master, and I've foisted it on my work instance too---ostensibly tracking stable there, but ;)

Okay, I got it! For future reference if anyone in a similar situation is stumbling across this and wants a fully working example to go off of, my more-than-a-little-cargo-culted code is currently:

Many thanks, @20after4! That all largely did it; in addition to setting up the object a bit wrong (I knew it was a ManiphestTask instance, but was failing to get the actual object of it), I was also just using essentially my:custom-field rather than std:maniphest:my:custom-field.

Does appear fixed in latest master!

I saw that in my searching but I just end up with Argument 1 passed to PhabricatorCustomField::getObjectField() must implement interface PhabricatorCustomFieldInterface whenever I try to use it, perhaps because I'm unsure what to actually pass it as the $object other than $this, though I second-guess my second-guessing because ManifestCustomField, which I'm extending, does seem to have the interface the error is claiming I'm missing?