From the exception

STDERR
waiting for lock on working directory of /var/repo/8 held by process '112297' on host 'ec6149cd0a0b/f000037a'

It sounds like another hg process is operating on that repo at the time.

Oh I completely misread your question, my mistake. I’m not actually sure what the data source query is.

Looks like create a brand new repository then navigate to it in Diffusion. I ran across this same issue.

I don't think this is an appropriate change, instead passing null into PhutilCommandString should be fixed. From the trace on T15367 it looks like a more appropriate fix might be updating ArcanistGitAPI::hasLocalCommit() to return false if $commit is null, or possibly updating ArcanistDifferentialDependencyGraph::loadEdges to check for null. I'm not sure under what circumstances it would end up with a null value though. In some basic testing the query it's doing does not return null for me.

It looks like upstream just straight-up removed the call to utf8_decode() in the master branch: https://secure.phabricator.com/diffusion/ARC/browse/master/src/utils/utf8.php$290-292

There is some support for this today, I have worked with dependent revisions in the past. There are some gaps but it’s possible today. I’ll look through my notes but I think this requires a fair amount of additional state tracking as commits change on local machines. I haven’t fully thought through it all but I think an ideal solution would be something like mercurial’s “evolve”, but that is likely a ton of work.

There’s possibly other reasons why they left it undocumented but it was a while back and I haven’t gone digging in the upstream for details.

Historically the reason why these aren’t documented is that they originally required installing 3rd party tools on the server. They were documented in tasks upstream but there was a security issue found with using graphviz so at that time out of caution they reimplemented figlet and cowsay in php rather than passing arguments to a 3rd party executable. After the implementation change documentation was never updated.

Oh I didn't realize it wasn't documented.

For a basic test additional compressed figlet font files have to be installed. I think it’s under src/support/figlet or src/resources/figlet or similar - pretty sure there’s a readme file in the location indicating it goes there. Then in a comment use remarkup to use figlet and verify it’s using the font you installed. For the zip check presumably you’d need to update php.ini to disable the zip extension.

We really need to turn on T15042 so diffs can be landed from the webpage

One other thing we’ll need to address is the current code sharing between arcanist and phorge. I’m not sure the full scope of what Phorge relies on from arcanist but I think there’sa fair amount. We can probably get an idea by looking at the libphutil repo which was the shared library between the two which was eventually merged into arcanist

I was similarly looking at lua for the same reason as it's used by neovim 😆 . There are a few libraries for lua in rust but the one that seems recently active is mlua, which doesn't implement lua execution in rust but binds to lua binary/library. If we go the route of binding to another library/binary then our build/package would have to include the lua library file too (though it may be possible to embed it?). Something like Rhai (or there's also Rune and a few others), are implemented fully in Rust so there's less to worry about during the build/package process. I wasn't sold one way or the other but wanted to check out Lua along with some of the others to see how well they turn out.

I’m fully aware of the friction that comes up trying to get developers using arcanist, the difficulties with PHP, the complexity in not understanding what’s going on, etc. and also familiar with the benefits of a compiled binary solution.

Hah this has been something spinning in the back of my mind for a while. One thing that will be difficult to support in something like Rust (not sure about Go) is that the PHP arcanist allows for very easily extending by dropping in your own PHP files to the extensions folder.

In upstream phabricator I worked with Evan to update the Mercurial API in a way that all mercurial commands/futures are executed through a common path and allow making modifications to only those executions. For this we should look at something similar so that we're only passing $HOME to git commands and not to others.

From https://drewdevault.com/2018/10/05/Dont-sign-a-CLA.html

Many people, myself included, contribute to open source projects under the assumption that my contributions will help serve a project which continues to be open source in perpetuity, and a CLA provides a means for the project maintainers to circumvent that.

Assumption here is key. The entire purpose of a CLA is to remove this assumption and clarify how contributions are managed. This post and disposition is based entirely around the organization receiving contributions will behave in an adversarial manner in the future. If the organization doesn't earn your trust then why trust them with your contributions?

Could you check the server configuration of php.ini for the value of variable_orders? This open task on phab suggests that on servers it should enforce including E causing phab's environment to be passed to sub-commands, but does not want to mess with it on users' machines.

Thanks for the thorough review

Thank you for making the update. I'll do some testing and likely submit this upstream as well.

I did some digging yesterday around PHP versions.

I've got a docker-compose setup working which runs mariadb and phabricator/phorge against shared/mounted phabricator/arcanist folders to allow easy local-modifications+. The readme outlines basic steps to get running. I've tried to keep it as minimal as possible while also making sure standard/default configurations are made so you can get up and running as soon as possible. Currently it's setup with php 7.4 but I'll be looking to update to 8.1 or 8.2. There are probably other minor things that I'll need to update with it as I use it more but I think this should generally work.

We have not migrated to using Phorge of Phabricator, so issues that crop up which are critical will be updates I submit upstream.

I wanted to set up some docker/compose file or possibly a VM but didn’t get far since neither of those are great solutions on windows, primarily for getting local code into the container/vm. My goal would be to get a quick setup time with a rapid dev/test cycle. For me to make progress I’ll likely have to switch to mac or Linux.

Getting set up with a development environment (including database~) along with configuring the local instance and populating it with sample data is extremely daunting and is frankly why I haven’t done much contributing. I lost my dev environment a few years ago and have tried only once to get set back up, spent a few hours and never came back to it. It doesn’t help that arcanist’s self linter isn’t usable on windows systems.

Okay real accept

Thank you for investigating! I think this is reasonable to land, given the investigation and testing there aren’t any immediate issues that seem to crop up on mobile.

From a usability perspective this feels nice to be immediately at something more useful. I would just try to find why the dashboard page works as expected but the main landing page doesn’t. If this change is still the underlying reason it seems good to me.

Does this change anything other than the landing page? When using mobile the first thing I do is click the link to dashboard and it shows properly there. Any idea why the home page behaves differently from the dashboard page?

Somewhat related - see T15050

Could it be cached?

Could you elaborate on what this would help with? I recall reading something in Phabricator’s past that the current url scheme is intentional as opposed to using the monogram/slug. I did a quick search and couldn’t find much, though in this change release
https://secure.phabricator.com/w/changelog/2015.51/

Removed dedicated titles/slugs. Phame posts now automatically generate readable URIs, but the slugs are no longer semantic.

We should investigate the history related to the current URL scheme before making a change. My suspicion is that it has to do with phase posts being “public” or published where having a url with part of the title is very common for linking across other content.

Sorry about the delay on this. I think the emails didn't go out until later and I've not had much time to dedicate to this project as expected. As of today's meeting the current plan is for @avivey to do the merge with latest updates from upstream and push, sans review.

@dcog I think the differences with the Harbormaster changes are due to the different approach taken. We planned to do the approach which you took in D25036 which re-played the Phorge diffs on top of phabricator, however in D25040 I just did a merge of the phab/master branch into phorge/master where the Harbormaster changes already existed. Since upstream didn't modify the same Harbormaster files there were no conflicts and things merged appropriately. I did a sanity check of files changed on D25005 with the files changed on D25040.

Do we even have servers to run the tests on?

I did not think we had Harbormaster set up to run unit tests - I think that involves configuring both Harbormaster and Drydock, and possibly Almanac which I don't think anyone has done.

Though it does appear additional work has been landing upstream today

Any concerns about landing those changes? Once I land I'll see about updating this instance which should make accessing the repositories possible again.

I had to skip unit tests because phabricator/phorge unit tests require a local database to test against which I don't have setup. The lint failures are either pre-existing TODO's being flagged or the newest lint which catches product name literals. We should fix the literals but I don't want to fix that as part of the merge -- would rather do that in a separate change.

Unit tests all pass. For the two lint errors, one is erroneous checking characters used in a non-code file, the other is pre-existing and fine to leave alone.

Merged the arcanist repository in D25039

It looks like upstream has issued a number of updates which we'll want to pull in. From {E4} we discussed doing the following:

Thank you for these write-ups, I'll need more time to review however I noticed Evan recently started a task in the upstream where it looks like he's investigating compiling PHP to a library for use with a custom native entrypoint which would allow distributing arcanist as a single binary (he estimates ~10mb in size).
https://secure.phabricator.com/T13675

Evan recently landed a boatload of changes to address this under https://secure.phabricator.com/T13658

There is quite a bit of text that is setup like this:

pht(
  'blah blah blah %s blah blah'.
  'blah blah Phabricator blah %s'.
  'blah blah.',
  $var1,
  $var2);

A few thoughts. This sounds like a great idea as searching by article title seems a little fragile as you mention. I think a good practice for using the proposed @link would be to fully namespace it somehow like @link development.processes.i18n, though I'm not totally sure what that looks like as I'm not familiar with the Diviner format or structure. If we have the use of namespaces then managing multiple @link declarations might lead to confusion or tedious to maintain. To me this also feels more similar to something like an @id rather than @link. What are your thoughts?

A highly unfortunate side-effect of T15077: Rebrand: Tracking task is that it will invalidate a ton of translations. My guess is that upstream did not want to maintain these translations as part of the release product, possibly due to not requiring translations be part of the Phabricator release process. If we pull them into the Phorge codebase then we would likely need to update all translations for any text changes made during development, prior to release. I think it would make sense to host the translations in a repository here but I would worry about them quickly falling out of date. Handling of translations is likely a larger-sized project that we would need help managing.

As part of {E1} we reviewed this as a priority item, and have created T15077: Rebrand: Tracking task for concrete first steps forwards. There is a lot of text to update and review and that task is setup with instructions on how we're approaching it as well as listing out all the individual applications to update. Anyone interested in assisting please review that task and feel free to put your name on an application/folder, as well as ask any questions for clarification.

I put up some coding guidelines that I could recall from when I was working with upstream on example changes. I won't be back at my home office for another week so there may be some things I'm missing but I think a number of things were covered/discussed with Evan on the example changes in https://secure.phabricator.com/D21712.