Okay I have these changes in and verified that things seem to be working fine with mercurial 5.8, though I'm not sure your thoughts on requiring mercurial 4.6 as the minimum version. If we restore the hg annotate --debug then the minimum version required would only jump to 2.4.

I should probably just set up a blog or something since I don't expect to bring any microcontroller components upstream, but until then:

According to their changelog the {p1node} style was added in 2.4 (2012) and was deprecated in 4.9 (2019) in favor of the new {p1.node} format
https://www.mercurial-scm.org/wiki/WhatsNew/Archive#Mercurial_2.4_.282012-11-01.29

I started a draft change in D21679. I also have changes for rARC but haven't yet created a diff for that (or yet figured out the exact versions to define)

Ah thank you for those details for the better change. I was planning to play around with what would be needed to remove the --debug flag(s) but I hadn't yet gone into the details. I'll take a look at these changes. From quick testing on recent mercurial versions (5.8) it looks like the output does not include the local revision number, e.g instead of
693:8b39f63eb209dd2bdfd4bd3d0721a9e38d75a6d3 -1:0000000000000000000000000000000000000000
it prints out
8b39f63eb209dd2bdfd4bd3d0721a9e38d75a6d3 0000000000000000000000000000000000000000

(DiffusionLowLevelMercurialPathsQuery has an example of using PhutilBinaryAnalyzer to do a Mercurial capability test.)

On navigating the version stuff, I think the pathway would be:

Keep the protocol/domain on one line and the path on another (in this case path is <80 chars)?

For the invalid branch cache message remove the (served): bit which might differ on hosted vs. observed repositories.

I removed the "install RHEL" and "install Ubuntu" scripts outright since I don't have any reasonable way to test them and don't plan to maintain them.

Ah I did come across these as well and forgot to note.

In T13658#255994, @epriestley wrote:

Create Platform::getProjectRepo() to return "phabricator", or instead detect the repository name.

I suspect having this method do anything nontrivial may lead to some weird boostrapping issues, where it gets called very early during startup or with a partially built environment or during exception handling or whatever and not everything you expect to be available is actually available, so I suspect you'll have the best luck by just hard-coding this.

(For example, Phabricator reads PHABRICATOR_INSTANCE from the environment very early.)

Ah I did have a suspicion that would be tricky but was thinking to give it a shot. Hardcoding is probably just going to be easiest.

Proof-of-concept only for class_alias():

This is a bit out there, but: PHP once had something called classkit and later runkit, which perhaps exists as runkit7 now, that let you dynamically rename classes at runtime. In theory, you could use this as a compatibility layer to support mass renaming of classes: if code asks for PhabricatorXYZ, look for GenericXYZ (or XYZ, or consult a mapping), then make a runtime copy of the class. This narrow capability may be in PHP's core as class_alias(), now.

Create Platform::getProjectRepo() to return "phabricator", or instead detect the repository name.

As another test I tried creating a new commit on Windows and using smart-quotes and em-dash in the commit message and mercurial bombed with

$ hg ci # nvim opened an editor in UTF-8 encoding mode and let me write in a commit message: Test commit with “smart quotes” and "em—dash"
transaction abort!
rollback completed
note: commit message saved in .hg\last-message.txt
note: use 'hg commit --logfile .hg/last-message.txt --edit' to reuse it
abort: decoding near 't quotesΓÇ¥ and "emΓ': 'charmap' codec can't decode byte 0x9d in position 34: character maps to <undefined>!

I ran through another test just in case and things do seem to function fine. Another interesting point is when using nvim on Windows it will properly render the smart-quotes and em-dash, but mercruial's output uses the weird characters. Just in case I made sure to test having smart quotes and em-dash both in the Title and Summary fields as well as the content of the file change. Patching and landing the change from Windows, then pulling the commit onto the Mac and the end result on the Mac looks correct for all places.

The results in T13649 -- where none of these results actually print a character that anyone would consider to be a "smart quote" (?) -- aren't exactly inspiring, but I think this is a step forward at least.

Interestingly this is the output I get when using hg log to print out the commit message containing smart quotes with different encodings -- this behavior is the the same for both PowerShell (chcp 65001) and cmd.exe (chcp 437) and no errors occur.

$ hg log -r tip --template "{desc}" # "default" encoding
A test

I think the global flag is reasonable.

In Mercurial, with certain character sets, some arc workflows may fail in arc-hg while trying to perform UTF8 operations.

I'm doing some testing to find an appropriate update to arcanist for this. I ran into another issue, when patching down a revision which has unicode characters in the summary on a windows machine. I could try to whack-a-mole these different issues but since Mercurial's --encoding argument is a global option do you think it would be wise to update ArcanistMercurialAPI::buildLocalFuture() with this?

diff --git a/src/repository/api/ArcanistMercurialAPI.php b/src/repository/api/ArcanistMercurialAPI.php
index e5c2078b..ac72c356 100644
--- a/src/repository/api/ArcanistMercurialAPI.php
+++ b/src/repository/api/ArcanistMercurialAPI.php
@@ -15,7 +15,7 @@ final class ArcanistMercurialAPI extends ArcanistRepositoryAPI {
   protected function buildLocalFuture(array $argv) {
     $env = $this->getMercurialEnvironmentVariables();

Oops -- I assumed you were already in Blessed Committers. I added you, you should be able to either arc land or "Land Revision" now (if arc diff uploaded to staging properly). See that project description for some details, or yell if you're still having issues.

For landing the revision can that only be done through the "Land Revision" button? It's greyed out for me.

Re-balance the text line formatting with the new phrasing

Update the phrasing

Oh, just for completeness -- you can trigger the first message by visiting this URI while logged out (e.g., in an incognito window):

• Allow "owners.search" API to read this setting.

Thank you! Looks like it worked.

I added you to Blessed Committers, so you should be able to land this yourself. See that project description for guidance, or let me know if you run into issues.

(That was really me.)

I did see that, but @epriestley (or possibly an impostor) said:

I think a reasonable strategy for the moment is just to send patches upstream for review normally (with me as a reviewer) until I stop getting to them or it's clear that we don't have similar viewpoints on what constitutes a desirable patch.

Wondering if you saw:

Effective June 1, 2021: Phabricator is no longer actively maintained.

My company was a loving user of Phabricator (local server!) for over 10 years. I still fondly remember the discussions here and talking through new applications, testing changes, and so much more. I know that the use of this tool permanently shaped hundreds of engineers' views on code quality, review, the software development lifecycle, and so on. It will be missed.

Thank you @epriestley and all of Phacility. Phabricator is a shining example of a well-engineered product that itself encourages better engineering processes and having fun while doing so. I had a great time learning and using Phabricator and it has left a big impact. I only wish I could have been more involved in the development and community. Wishing everyone the best!

@avivey: a few folks have started discussing collaboration in the #phabricator channel on libera.chat irc network.

Thank you @epriestley (and @btrahan, @chad, and others) for the great work done here!

I could not find in the documentation how are we supposed to set a value for a custom field of type "user".
In particular, I am looking at doing this: set the default value to the current user (the user creating the Maniphest task)

This is approximately working now, although the "button" is currently this mess:

See T13656 for followup.

Instances technically have a formal "Deleted" status -- but it isn't really used by anything, nothing ever puts them into that status, and there are no instances in that status. For consistency with existing CLI workflows, I'm going to rename this to "Destroyed".

A related issue is that I think nothing currently destroys S3 data. For most instances this isn't significant, but it isn't helping anything. This should likely be part of the database destruction step, although it can probably interact with the S3 bucket directly.