Downloaded via the git Repos. Added the Databases from ./bin/storage databases by hand in Plesk and perfomed the "./bin/storage upgrade --force".
- Queries
- All Stories
- Search
- Advanced Search
- Transactions
- Transaction Logs
All Stories
Dec 11 2015
Hi this files.viewable-mime-types doesn't seem to apply to desktop since testing using an iPhone 6 plus using safari and using a windows 10, edge and internet explorer the iPhone seems to register files.viewable-mime-types and follows what ever is set in it but on desktop it doesn't since for example going to https://phabricator.wikimedia.org/F3069835 on iPhone and then click download it lets you view the raw without needing to download but doing the same on desktop doesn't it downloads the file instead of viewing the file in raw.
Can't reproduce:
$ ./bin/storage --namespace t9962b upgrade --force Loading quickstart template... Applying patch 'phabricator:db.xhpast'... Applying patch 'phabricator:20150906.mailinglist.sql'... Applying patch 'phabricator:20150930.drydock.log.1.sql'... Applying patch 'phabricator:20151001.drydock.rname.1.sql'... Applying patch 'phabricator:20151002.dashboard.status.1.sql'... Applying patch 'phabricator:20151002.harbormaster.bparam.1.sql'... Applying patch 'phabricator:20151009.drydock.auth.1.sql'... Applying patch 'phabricator:20151010.drydock.auth.2.sql'... Applying patch 'phabricator:20151013.drydock.op.1.sql'... Applying patch 'phabricator:20151023.harborpolicy.1.sql'... Applying patch 'phabricator:20151023.harborpolicy.2.php'... Applying patch 'phabricator:20151023.patchduration.sql'... Applying patch 'phabricator:20151030.harbormaster.initiator.sql'... Applying patch 'phabricator:20151106.editengine.1.table.sql'... Applying patch 'phabricator:20151106.editengine.2.xactions.sql'... Applying patch 'phabricator:20151106.phame.post.mailkey.1.sql'... Applying patch 'phabricator:20151106.phame.post.mailkey.2.php'... Applying patch 'phabricator:20151107.phame.blog.mailkey.1.sql'... Applying patch 'phabricator:20151107.phame.blog.mailkey.2.php'... Applying patch 'phabricator:20151108.phame.blog.joinpolicy.sql'... Applying patch 'phabricator:20151108.xhpast.stderr.sql'... Applying patch 'phabricator:20151109.phame.post.comments.1.sql'... Applying patch 'phabricator:20151109.repository.coverage.1.sql'... Applying patch 'phabricator:20151109.xhpast.db.1.sql'... Applying patch 'phabricator:20151109.xhpast.db.2.sql'... Applying patch 'phabricator:20151110.daemonenvhash.sql'... Applying patch 'phabricator:20151111.phame.blog.archive.1.sql'... Applying patch 'phabricator:20151111.phame.blog.archive.2.sql'... Applying patch 'phabricator:20151112.herald.edge.sql'... Applying patch 'phabricator:20151116.owners.edge.sql'... Applying patch 'phabricator:20151128.phame.blog.picture.1.sql'... Applying patch 'phabricator:20151130.phurl.mailkey.1.sql'... Applying patch 'phabricator:20151130.phurl.mailkey.2.php'... Applying patch 'phabricator:20151202.versioneddraft.1.sql'... Applying patch 'phabricator:20151207.editengine.1.sql'... Applying patch 'phabricator:20151210.land.1.refphid.sql'... Applying patch 'phabricator:20151210.land.2.refphid.php'... Storage is up to date. Use 'storage status' for details. Verifying database schemata...
Is there a perspective on doing this any soon? Or too little resources?
Multiple different ways of proceeding. Current way, while not bad, has it's downsides.
In T9897#148464, @epriestley wrote:I eventually got this live. blog.phacility.com is a little plain now, but seems to work fine:
I eventually got this live. blog.phacility.com is a little plain now, but seems to work fine:
@andrew-dixon Sorry, there's no secret internal tracker full of juicy updates that we're hiding from the public. If we haven't updated a task, there aren't any updates on it. See Planning for a little more discussion on this in general.
@epriestley Any update on this, I'm seeing this issue with my hg repo, only have one repo and I don't think it has loads of branches and it is creating a load average of 25 and 100% CPU on the VM I'm running Phabricator on and it is almost unusable because of it. Thanks.
- Send rules upstream for now (like with the Korean rules).
- We'll probably make this modular eventually.
This has been in production for a while and seems to be working correctly. New rules are:
Closing this out since there's nothing actionable here.
I'm planning to just remove skin support in T9897.
Assuming this is in good shape now.
I believe this was fixed by D14511.
This was fixed in connection with T9825.
I can't reproduce this. Here's what I did:
Side question, so I can submit a patch, is it a libphutil way to :
if (workflow_os == "Windows") { exec(window_feature); } else { exec(unix_feature); };
This was resolved by @chad in T9609: Really really wide tables in Remarkup should scroll
Briefly, T9529 discusses some server-side system running on revisions that's live in your environment, presumably. Its current behavior is something like this:
T8378 discusses a milder case of this sort of thing but I think the logic here applies to it as well.
sweet. I am sure we can work with those. I think Herald Actions in itself should work pretty easily in our existing workflow. I am very excited about server-side lint, but a bit more documentation about them would help me out. I can't understand it fully with your comments :)
I think T8405 and this are both basically discussing the same use case, which I understand to be:
I think this behavior is reasonable as-is.
See Contributing Feature Requests. If you're aren't sure what we mean by a "root problem", see Describing Root Problems.
No idea how to reproduce, no other reports.
Dec 10 2015
This behavior should be more reasonable at HEAD. In particular:
After D14737, we will now show this information in the UI if it's available. Here are the requirements:
This should be fixed at HEAD. Let us know if we missed anything or if you run into anything else. Thanks for the report!
Someone actually wants this, so I'll configure it during the deploy on Saturday.
Thanks for checking, that's quite helpful.
git branch --no-color and git branch --color=never both work, but Git 1.7.1 does not like git branch --no-column.
I don't know how exactly, but this error is related to T1116. Basically, adding this code fixes the described issue:
Ah. Yes, I agree.
I don't think that string is one of ours. Does it appear in flarc?
