T11044 makes this both more relevant and somewhat easier.

"Autoclose" and "Track Only" configurations are limited to branches, and do not account for arbitrary tags/refs. For now, I think we can assume tags are always autoclose/track, but may need to refine this in the future. I'd ideally like to replace autoclose with "fork" (T10691) rather than introducing tag(regexp(...)) or whatever, but that may be a long road.

To revive deleted commits when they are re-pushed, I think it is sufficient to ignore deleted commits when filling the discovery cache (PhabricatorRepositoryDiscoveryEngine->fillCommitCache()) and allow recordCommit() to detect existing commits and revive them.

Current state of the world after D16108 is:

Thanks for the report! This should be fixed once D16128 is reviewed, likely later today.

Thanks for testing, that's quite helpful.

I don't see how Herald rules are related to the provided "example use case" (maybe because it's unclear to me what "MUST acknowledge" actually means). Maniphest's advanced search already allows to combine "Created Before" and "Updated After" to address that "common need" - no Herald needed.

In T8510#179818, @epriestley wrote:

D16094 should improve things, let me know if you identify specific problems after deploying that. It's deployed on this server now, although we have fewer similarly-named projects so it's harder to see the effects.

We have a large user base using various install locations on their PC's. The issue has come about following a recent upgrade from a 2015 version with more than one person affected.
If you look at the code I cant see why you would need write access - it is just processing path strings.
Anyway I have moved the install to your suggested directory but with no change to the fault symptom.

Another example use case: the ability to perform advanced searches based on report history criteria and to send "whines" (as on bugzilla) is needed for any project that wishes to join https://bestpractices.coreinfrastructure.org/ , namely the criteria:

The project MUST acknowledge a majority of bug reports submitted in the last 2-12 months (inclusive); the response need not include a fix.
The project SHOULD respond to most enhancement requests in the last 2-12 months (inclusive). The project MAY choose not to respond.

On second thoughts, the flexibility of a Herald rule may already be better for me, as I want to filter out Merge Commits from auditing (at least when they are merged by an Owner), since the individual commits that are merged already have their own audit.

As someone who regularly uses Arcanist on Windows, I can't say I've seen this issue. You should try placing Arcanist in a writable directory, like C:\Tools\Arcanist. Installing it into "Program Files" is probably not ideal, as that's not a writable location.

Yeah, this is a known bug with aborting builds. It doesn't actually functionally impact anything (you can still restart the builds later, etc.)

In T11153#180624, @epriestley wrote:

You can determine both of these from the harbormaster step dependency tree.

Today, yes, but not if the tree includes custom build steps which allocate resources or if we add "if <condition>, run <another build plan>" or "foreach <item> in <artifact>, run <another build plan with 'item' as an input>". I think these capabilities are probably more interesting than being able to automatically count how many resources a build needs is.

We could do this when a plan is predictable, although an automatic lock acquisition scheme could fail in cases where an explicit one would succeed: for example, when a plan is edited, we may change discovered lock order from "A, B" to "B, A", and builds on the new version of the plan could deadlock with currently-executing builds. If both versions of the plan acquire locks explicitly builds will be able to survive edits.

Generally, I think resource autorelease (using @hach-que's rule) is probably the shortest pathway forward here. You'll still have a fairness problem, but you should get better utilization from the pool and be deadlock-proof on "A", "A" type acquisitions. This also tends to trigger less adjacent work than new resource types would.

Being completely fair also means we must execute without parallelism, because if we start position 2 without waiting for position 1 to finish it might win, and this could keep happening forever.

The expectation is that allocation should generally be fair ("first come, first serve") when no allocations fail.

It's causing a lot of pain mostly because we don't have good visibility into it happening, and we don't have any good way to react to it once we get close to fully saturated.

You can determine both of these from the harbormaster step dependency tree.

You don't really need an explicit release lease to solve this problem. Nor do you need an explicit locking system for resources. You can determine both of these from the harbormaster step dependency tree.

I'm planning to do this:

See some prior discussion in T10081, which I'm going to merge here.

@chad some of your commits are affected too, for example rP695f0b09b23761c813b015c2b62075cbdee1de59, better if you add for example a Ref T99999 ;)

I know you have focussed on the missing background, but I'm not overly fussed about that. But I am surprised that the commit subject shown twice in a row, once truncated inside a table and once not, is anything else but a bug.

@skundam this is not the expected way to get support. Please see Support Resources.

Another, very legitimate example, would be diacritic characters in localized README (or other) files. Until UTF-8 support is not present in text linter, i simply have to disable linter for files that have words like "żółć" in them. Plus using ¯\_(ツ)_/¯ in doc would be beneficial to some 😉

I think this also increases the chance that users accidentally disable or misconfigure (e.g., by misusing Match user) administrative sshd by requiring more extensive changes to its configuration. Users locking themselves out of the host is the worst outcome of a configuration attempt by a huge margin.

I know I didn't retrieve all the info you asked for, so let me know if you want to see anything else or want me to decode the base64 email body.

I've learned some interesting things.

without getting into whether it *can* be done, we looked into this recently and decided we actually liked the suggested approach.

Can you provide:

The bellow error is the one which I am getting and I am not able to create anything. Please help me.

Hi All,

 I am not able to setup git connected to phabricator. I did lots of research and was able to setup phabricator, local git, local SVN servers. But git and SVN are not getting connected to phabricator. 
 OR
In other words, I can say that we are not able to add the projects and code to phabricator through git. Can anybody help me in providing step by step documentation?.

Can anybody help me how to setup git connectivity in a local phabricator server?.

Do we have a detailed step by step documentation on this?.

i think my mail config is ok,
run ./bin/mail send-test is right,

Local Version Bitnami Phabricator 20160523-0

Microsoft is providing a way forward here with their implementation of OpenSSH.

According to release notes it was added in OpenSSL with version 4.4 (http://www.openssh.com/txt/release-4.4).