Got it. Another quick comment: arc branch unfortunately does not work well for the HEAD~ workflow.

See T11343 for discussion of automatic "Depends On" detection. Briefly: desirable, but also complicated in the general case.

Thanks for the explanations. I can appreciate the complexity and the multitudes of workflows which I am certainly not thinking of.

That explains it then; I'm not used to being complimented about my eyesight :P

Clearly we should have a Services starting with "CloudF..." header.

I'm using CloudFront. That explains why I ignored the note, though; it
doesn't apply to me!

Please read Contributing Feature Requests carefully before filing feature requests. In particular, we need you to describe a root problem (see Describing Root Problems).

@jonah214 said he's using CloudFront (AWS) while that note is about CloudFlare (an unrelated product/company with a nearly identical name) so I'm suspicious there may be more to this than meets the eye (or maybe CloudFront was a typo).

I think we owe @avivey another lunch at this pace. Such eyesight!

I added you to Community, so you should have sweeping janitorial powers now.

I must have missed what @avivey pointed out. Thanks! Sorry to bother you guys.

Did you see the note in https://secure.phabricator.com/book/phabricator/article/configuring_file_domain/#approach-cloudflare ?

I can't reproduce this. Here's what I did:

I'm curious, is there any other way to trigger Herald to process a Differential review *other* than uploading a new diff?

Yes! Thank you.. that's it, closing this question.

In T4181#133830, @kaismh wrote:

I have created an upstart service for Ubuntu 14.04 LTS. Create a file /etc/init/phd.conf and save the following:

I was not able to use this script in any of my installations, it always causes bootup/shutdown to hang and does not properly start the phd daemons. For some reason, phd for me has been very difficult to get up and running with upstart scripts. Whatever I do, calling service phd start always results in just a hang. If anyone has any insight into how I can do this, would be greatly appreciated. I'm running Ubuntu.

Yes, nothing is in the transcript, in other words, no job was triggered

I won't comment on the specifics, but have you looked at the herald transcript? I normally find the answer hiding in there.

For example, this is what it looks like on our instance:

no.. they've been a part of that project since the beginning

If you're not allowed to see PHID-PROJ-rwnekrajar5m6diprobx, it will not be returned from project.query. Herald should be seeing all projects though, so PHID-PROJ-quo7cpreceuh6hnor3pw missing is strange.

yes... they're secret :)

Is there anything special about the projects PHID-PROJ-rwnekrajar5m6diprobx and PHID-PROJ-quo7cpreceuh6hnor3pw? Is any of them secret?

I have had users request this as well and we actually have a custom application that makes use of this. When you do this you run into other problems such as harbormaster doesn't clean up after tasks. That becomes the job of Drydock and you will have to write your own drydock blueprint to do this in any kind of sane way.

I imagine this task is easier now that we have a "Move on Workboard" selector.

Thanks for the response, it does seem D15958 is what I am looking for.

In T5024#59425, @epriestley wrote:

For the first case, maybe a column permalink would be a better solution? Then you could navigate back up the board easily. We can structure this as a search query instead (and it might not be bad to make that possible, for Dashboard panels) but it will lose some context. There's also no control which will easily let you select a column right now, and building a nice one is probably a fair bit of work (plus, it overlaps a lot with some other less well-defined tasks and infrastructure-blocked things).

This doesn't appear to be a bug report. See Support Resources for how to get help with Phabricator.

This doesn't appear to be a bug report. See Support Resources for how to get help with Phabricator.

svn is used today. It never used before. So, I not sure whether it can work before. My install is out of date, this means need to update phabricator?

I think the root problem here is that "Herald added a subscriber: $user" is seen as email-spammy yet people are unwilling to edit their preferences to disable notifications for subscription-changes.

Does the error occur after you update Phabricator? Your install is out of date.

This doesn't appear to be a valid bug report. You must update Phabricator before filing a bug report (your logs indicate you are a month behind), and you must provide steps we can reproduce the bug.

Though I don't completely understand the specifics, I do have this issue resolved.

#1146: Table 'phabricator_metamta.metamta_mailinglist' doesn't exist

is an error from MySQL, and not from Phabricator. I believe the problem started when I restored the database from a backup. Rather that using a dump/restore, I rolled back to a previous filesystem snapshot on my database server. That filesystem snapshot contained :

mysql/phabricator_metamta/metamta_mailinglist.frm	
mysql/phabricator_metamta/metamta_mailinglist.ibd

database files. That particular table, however, no longer exists in the current versions of Phabricator. Once I removed those two files from the database server and restarted the MySQL server, the bin/storage upgrade command worked without error.

Awesome, thanks @epriestley. The update cron script runs that bin/storage upgrade every time.

Note that you need to bin/storage upgrade after picking up D16312 for this change to take effect. You should normally be doing this anyway, just mentioning it since it's not obvious that this would require database adjustments.

I think arc actually calls differential.getcommitmessage and then passes the result right back to differential.parsecommitmessage to split it into fields. That could/should work differently than it does.

This is desirable, but complicated in the general case. T3875 (and T3875#182020 in particular) has some discussion of a similar identification problem at the other end of the workflow, in arc land.

Where did the phid get to the user anyway? If it's arc diff --update, it shouldn't try to parse the comment, and if it's arc diff --create, it shouldn't have any tags?

We can have this render "Tags: PHID-PROJ-abcdef" instead, which is an "improvement".

No this is just a general bug report since it's a fairly confusing error message for end users.

Are you looking for alternative ways to block commits, or is this a bug report about "arc diff fails when revision has secret project tags?"

Obviously I can implement this myself locally, but if it's a lousy idea for whatever reason, I'm hoping filing this request will cause someone to warn me off it.

T8200 describes a somewhat-similar issue.

Well, that sounds scary.

In general we want people to update if possible before filing a bug report. The reason is most real "bugs" are fixed usually same day reported. For example we had a recent "Repository is not attached" exception that was fixed same day, but we're still getting reports trickling in weeks later. Being on this week's stable is all we usually expect. HEAD of master is better, but not required.

I'm trying to figure out if I destroyed our files this weekend by migrating them or by using purge / compress.

Per above, I'd like to just fix issues here rather than add an automatic compaction process. I don't currently know how to generate un-compact files in modern code.

Actually....

Presuming this is fixed / irrelevant / not scary / resolved / something since I don't think this went anywhere elese, yell if not or I just forgot something (or we can follow up after T11044 if this is waiting on that),

First I apologise if I somehow came across with any hostility, that was certainly not my intent.