• 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.

I'm going to merge this into T5155 because I imagine that will be the way in which this is resolved.

Lol

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.

I applied a patch locally in an attempt to troubleshoot this issue:

I applied the following change locally. I'm not convinced that it is the most correct solution, but it seems to have worked for our install:

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

I guess the issue is knowing which test engine to run... Okay so a file in __tests__/ changes, do I need to invoke the PHP tests or the JS tests? Given the repository structure of this project we could probably just change the regex from \\.php$ to ^src/. Longer term, I wanted a way to map files to tests in a much more flexible way, such as mapping ^src/lint/linter/__tests__/xml/ to src/lint/linter/__tests__/ArcanistXmlLinterTestCase.php.

--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.

How about something like this?