It looks like the DELETE statements can not be expressed in a way which doesn't upset the "unsafeness detector", even when explicitly ordered by primary key. I think this is the relevant MySQL issue:

I see, it makes sense now that I know what's going on. Not sure if there's a better way to write it honestly.

Here's the section that's intended to explain it. This applies to Mercurial, too (in theory) which is why we don't explicitly mention git fetch.

Got it, thanks!

@chad, I've updated the title to reflect the updated (and confirmed) duplication instructions. The specific problem is that, if a project has subprojects, then any milestones belonging to the base project cannot be modified.

Alternatively it seems like we can switch to MIXED mode and recommend that, but some installs probably won't be able to and I'm not sure what the tradeoffs are.

It should be fixed in HEAD, it just only regenerates once every 24 hours or something I think.

https://secure.phabricator.com/book/phabricator/article/notifications/ needs to be modified to fit the new world.

Should be fixed in HEAD of master. Thanks for the report!

The staging repository allows you to git fetch the change to the build server (which is easier and more reliable), instead of using arc patch.

The diagnostically useful information from the trace is that this:

We're currently using columns as lightweight "subprojects" - i.e. our Bugs project has a FIXME column for higher-priority bugs. Would the recommendation here be to just use a subproject?

In https://<your.install.com>/config/history/, is there a configuration change of any kind shortly before 17:19 UTC?

I see. The rule you showed was actually exactly how I set this up before adding a staging repo.

If you have this in mind, I'm not looking for batches renaming or anything like this.

That's already the root problem 😉

For design reference, here's the GitHub version of this mail (each comment arrives in a separate mail):

Thanks Evan!

Why are you renaming columns?

Yeah, I'm familiar with monit, and I think it will work decently well for this situation. Unfortunately, the current environment standardized on daemontools instead of monit.

I slightly reduced the amount of header magic, and the notification stuff is now cluster-ready (in theory, at least). I'm planning to get notifications, web nodes, and databases redundant in production today, and maybe repositories/daemons if nothing else comes up. No issues with repo bookkeeping so far but even if it's smooth sailing it needs a fair bit of UI work, and same with the daemons.

rCOREf9b858d57460 gives web nodes sudo access to svnserve when they're proxying SSH connections.

Tried running 2.6.2 on the server side, and that indeed does fix the bundle2 issue, but creates more issues when trying to push from a 3.7.3 hg client.. :-(

(Per T10799, T6878 is the underlying issue with why they don't import, but it's currently never materially useful to import them so this hasn't been a priority to fix. Empirically, they do not import on this install but builds work fine -- except see also T10667 for a weird special case mostly unique to this install.)

Staging is required (well, not strictly required, but strongly recommended) to setup CI.

Thanks for the reply. I may be confused then. Based on the Harbormaster documentation I understood that staging was required to setup CI. Please correct me if I'm wrong. This is my first time setting this up.

If I host externally, I basically lose the access control and herald rules, right?

We host most of our Mercurial repositories externally - this is primarily the infrastructure we had prior to adopting Phabricator. We have a few repositories hosted by Diffusion, however our server runs 2.6.2 which does not utilize the bundle2 protocol.

I am not sure exactly what you are trying to achieve, but if you want to do CI with differentials, just set up a herald rule to trigger a build plan when a diff is created / updated. This will trigger whether the staging commits are imported by phabricator or not.

Since the commit is not imported, I believe this is currently preventing me from setting up CI with Herald/Harbormaster/Jenkins.

Here's how I modified the configuration on this host (secure.phabricator.com) to account for this change.

I can not reproduce this issue by following your reproduction steps. Here's what I see on this install:

I can confirm this is fixed now.
Thanks, @vinzent @epriestley , for this ultra quick fix!

I've marked D15705 as fixing this, since it makes our interpretation of the path unambiguous: we would no longer interpret /ws/ as a request for namespace "ws".

@epriestley Thanks for the quick fix!

Sorry about breaking this -- there are a lot of large changes going in this week related to T10751, so master might be a little less stable than usual until the dust settles there.

just updated, it works now without cluster.addresses set.

This should now be fixed in HEAD.

This report does not include reproduction steps. See Providing Reproduction Steps for help.

Upgrade Phabricator. This is fixed in HEAD.