We could make make not actually depend on the timestamps on those files, conceivably (only on whether they exist).

(A similar block in shouldHideForFeed() prevents these from publishing redundant feed stories, and stops the actual notifications.)

Implementing this feature just involves deleting the code in PhabricatorApplicationTransaction->shouldHideForMail() which prevents these from sending mail.

What was getting cached that created an issue?

Closing for lack of feedback.

(For completeness.)

I don't plan to pursue this. I consider it highly desirable that users must explicitly grant permission to OAuth clients.

I expect to move this stuff into Locale subclasses eventually, but it's potentially performance-sensitive so I want to be careful when doing so.

• I closed the 002 services and opened the 003 services.
• I created a new instance, verified it allocated on 003, connected to it, pushed/pulled, ran backups, etc.

• I launched repo003 and db003 in the cluster.
• I created .phacility.net DNS entires for the hosts.
• I created ddata, dbak, rdata, rbak, and rlog volumes for the hosts and attached them.
• I created device entries for the hosts and *bak volumes.
• I created service entries for the new repox and dbx services.
• I used bin/remote deploy to deploy the hosts.

It looks like they're ordered by internal ID, which is often correlated with commit date but not always the same. This is just the default behavior of queries, not an intentional behavior.

This feels unexpected/weird enough to me to consider fixing at some point, but not really broken or particularly problematic.

In the Maven case, I think it's OK for the default behavior to be something like: mvn test always runs, even if you just update the README, and for future documentation to walk through users getting this kind of over-testing setup working first.

My gut is that it's OK to hand pretty broad "include" lists to most test engines and assume that they'll handle the mapping rules. Since the Phutil engine can do the right thing from any path, it seems OK to me to hand it pretty much anything.

This should now be fixed in HEAD. Thanks for the report! Let us know if you run into anything else.

Note that this particular "reverts" (with a commit hash followed by some noise) won't be recognized after this patch: the regexp will simply fail to match. I think this is correct, although we could plausibly be more aggressive about it. But I think most cases where we'd hit this are probably silly nonsense (say, in copy/pasted output from other tools that describes the context of a change) that users would expect not to match, and that sneaky "o" characters are probably a rare case.

Thanks! This is an extremely thorough and helpful bug report.

no one has ever reported an issue with an old version which we could not trivially resolve

It looks like --get-url was added in early 2011:

(Just clarifying the title so I don't confuse myself later about this relating to the "Projects" field.)

Our first spam! Exciting!

@cburroughs: Yes, this will support both hosted and external repositories.

Chain of Custody

--upload-xprofile is definitely more useful overall than --xprofile <file> since 99% of the time I've also done some approximation of that upload dance, it just feels a little weird for some stuff to take --xprofile <file> and some stuff to take --xprofile which takes no argument and means something completely different.

What file could I touch in a __tests__/ directory that shouldn't trigger tests in that directory?

This should be fixed at HEAD. Thanks for the report! Let us know if you run into anything else.

Oh, sorry -- after looking at it a little more, you certainly have that patch. I'll take a look at this, thanks.

Do you have rARCe5946ed?

I think --xprofile is provided by libphutil but it doesn't know about Phabricator. It seems sort-of-nice-to-have to have the raw version, maybe. Not sure how easy it is to add --upload-xprofile to arc.

I don't remember the last edge -> object conversion we did, I don't think we've done one for a while.

Edges have a data field, but you can't put keys on any of the data since it's just stored as a JSON blob. For example, it would be possible to store an awarderPHID in the data, but then as soon as you want to show a view of "all badges given by epriestley to other users" you can't query by it (since you'd have to load every edge, then deserialize all their JSON data, then look through it).

Since we're pushing everything to staging, I expect that to be covered here.

Pretty sure this is the same as T6076; I'm going to merge that here.