Pretty sure this is the same user as @9999999999, @Persona, @nagya and @nagym. They're just registering an account every day, being vaguely annoying, and then getting disabled. O.o

i am cloning repo in my local phabricator(ssh only read) and cloning repo in my notebook, then add new file in dir1 "test" and commit he in rSVNTEST then accept commit and i found this revision on my local phabricator where she all the same do not open for review code same all post revisions...

okey im trying pull test repo in my sandbox, but im not sure what it's working. Chad how you can see on offer connect in my local phabricator and see all your self ? :)

We're also not familiar with https://riouxsvn.com/, so maybe removing that host as a variable would help. Phabricator has built in SVN hosting.

Unfortunately no, we need reproduction steps to be able to move further. We need some means of observing the issue in a local sandbox so we can be sure we've found and fixed the right bug. That might mean you isolating the offending commit that is giving Phabricator trouble, breaking down to a minimal test case, and pushing an example to rSVNTEST for us to inspect.

chad you have any ideas what's wrong in my local phabricator or whath next steps i have to do for resove it's problem?

Yeah footer links aren't a great place for a mailto:. Overall you're better making a Phriction document with all the vital information, and have a link to that in the footer under "Contact Review Team" or something. Just an email link without context seems a like a wasted opportunity.

D15358 should fix this by declaring the property. Nice catch on finding this!

Specifically, the issue is that this class extends Phobject, which implements __set() and throws when an undeclared property is written to. The exception is swallowed elsewhere in the stack.

This is detailed in T10463, but the API changes seem to have deployed with only a few minor rough patches, so we're currently on track to deploy everything else next Saturday (March 5).

Test instance workflow looks good, and general monitoring also looks clean. I'll keep an eye on things but I think we're in the clear.

Also, the backup changes from last week (rCOREbf0c93a46f8b) seem to have worked correctly. The instances that were hitting problems and delays have written backups exactly on schedule every day since then.

Daemons look good -- we accumulated a bit of a queue of backup tasks while the tier was out of sync, but these have now almost completely flushed on their own.

I've deployed the remainder of the repo tier, and the auxiliary service tiers. I believe deployment is essentially complete.

repo001 seems to have gone smoothly and daemons/repositories are now restored, I'm deploying the remainder of the tier.

db tier is deployed, now deploying repo001.

I've upgraded db001 and sorted out host instances and service sync flows, which seem OK now. I'm going to upgrade the rest of the db tier.

web is sort of back up, but needs the new schema to actually make any progress, so this isn't conclusive. I'm deploying the db tier now to get the new schema.

• I stopped web.
• I deployed admin.
• I manually removed now-invalid configuration from instances and from Alamanac properties.
• I spot-checked instance/Almanac service relationships.
• I spot-checked Almanac service properties.
• I manually invoked almanac.service.search to look for issues, but everything looks good.

I've stopped the daemons. I'm going to stop the web tier, deploy admin, fix instance configuration, then deploy the web tier. I expect this to be the riskiest part of the upgrade.

I'm getting this underway now. I'm going to preemptively stop all daemons, which will pause repository imports, outgoing mail, etc. They'll be restarted at the end of the process.

I believe our Harbormaster log table is several GBs in size and by several GB I'm talking 20-80GB range depending on the last time I hard deleted the records.

When creating the first subproject there is a note that all members of the project will be moved to the subproject.

Pretty sure I can scope this into the current iteration under T10457 and provide some corresponding purge tools, just in case any installs hypothetically insert gigabytes of data into build logs.

In any case, this is definitely some kind of problem in your local environment and not an issue with the upstream. We can't and won't be able to reproduce it and can't help you with installation and setup issues (see Support Resources).

Oh, wait, you're actually on stable and just haven't updated master.

This column and the property for it were both removed in 32225d1 (Feb 8). You are running b5518d4b (Feb 7), but have somehow upgraded your database using a newer version of Phabricator.

A workaround is to write a wiki page like "how to get help with stuff" and put the link there.

My broad philosophical stance here is that engineers should be disciplined and professional about not killing enemy builds, but I think the complexity cost to put some more guard rails on the thing isn't overbearing and these additional policies are generally pretty reasonable and make sense, and have some redeeming value in preventing mistakes with tools like "Restart All Builds".

UPD: find error at "arc diff"

thank's, at ulr, I do it

./repository reparse --importing --all --trace  R10

They do lose access to managing both accounts which has caused a few issues around email addresses. It looks like we could have reduced massive pain on ourselves by letting users unlink ldap accounts and instructing them to link the new account.

Presuming resolved by D15350.

Hi Chad. Thanks for taking the time to post that, it's helpful. I don't mind too much that it's per commit rather than file but it would be nice to have a view that said "this file you have open, was audited in as part of commit A,B,C" .

Maybe also related, T10003. Do you have any special configuration for Maniphest?

You can check database status and issues in Config -> Database

Git says "Already up-to-date"
I did restart both nginx and php5-fpm many many times

See https://secure.phabricator.com/book/phabricator/article/repository_imports/

When we say "restart webserver", we mean Phabricator itself, which means php-fpm for you. See https://secure.phabricator.com/book/phabricator/article/restarting/ for more details.

Either your database didn't get updated, the code didn't fully download, or you didn't restart the webserver.

Maybe a more natural approach to this would be to add a "Notify" build step? We'd also need an "on failure" set of actions or something which implicitly accomplished the same goal, but that seems reasonable to me.