Phurl is a prototype, too.

See Prototype.

(There is also a different type of cache from <object hash -> metadata> we could build in Git, but that's kind of a lot of work.)

In SVN, we can use a different icon because we have prebuilt cache of file types (and must have this cache for other reasons, and can build this cache efficiently, and SVN distinguishes between binary and text files).

I had this same issue, I had to dig into the db to remove the duplicate phids

Yes, the problem is also mentioned there, thank you. I wasn't able to find it somehow.

D15483 changes the constant to 47 (15 window size + 32 for gzip + zlib), which should accept and decode the broadest possible range of inputs. If this somehow breaks something, 31 (15 window size + 16 for gzip only) is probably the next thing to try. See that change for discussion.

This is probably a variant on T4551.

(See also T2636 for previous discussion).

Pholio itself is getting fairly old, not sure when it'll get re-visited, maybe 6-12 months?

This is consistent with inline comments across all of Phabricator.

We'll try that in our next upgrade. Thanks for the help!

Here's a diff to make bin/storage adjust always run ANALYZE on every table after it makes other adjustments, but I'm not really sure if that's actually helpful or not (e.g., from the documentation, it sounds like the good analysis can be immediately overwritten by a bad one in some cases?):

I think so. Sorry for the originally misleading claim.Sorry for the originally misleading claim.

In T10560#165431, @epriestley wrote:

Should we get rid of the <commitID, isDirect, changeType> key, then?

Well, the docs suggest not doing that:

Should we get rid of the <commitID, isDirect, changeType> key, then?

The discrepancy between staging + production is almost certainly caused by the size of the data.

You do not need to create a secondary index on changeId as that is the leftmost part of the primary key. The secondary index just points to the primary index where the data is stored.

The underlying cause of the slowness is because the stats were completely off in the production table (was showing cardnality of 18 for changeId).

In T10427#161255, @urzds wrote:

I can confirm that, too.

@epriestley, first time I tried I just wasn't lucky enough to navigate to Config->Versions.
By the way I updated my Phabricator version and it works fine.

@jlvillapalos, can you shed some light on why you didn't include that information in the first place or how we could improve the process?

bin/remove destroy gives you a huge scary red skull-and-crossbones ASCII art for good reason, and you're accepting that issues like this may occur when you confirm the prompt.

The problem was encountered when we have deleted the existing repository with audits because we wanted to include not just the trunk but all its branches. The thing was that the deleted repository in Diffusion was not the first one to be imported again.

This transaction can only create a task into a column, it can't move a task. That's why the documentation says "Create into a workboard column.".

This is the version information, but it will be very useful to give instructions of where to look to get it.

@chad Probably the same purpose.

Is this different than T5214?

We'll consider adding a setup issue if we see other users having issues with this. Previously, we haven't, so we presume users having or uncommenting these blocks in the wild to be very rare.

I'd be OK with that. I already got our admin to resolve the problem for my install, so I only raised this thinking it would help others. A server configuration warning would also have worked to have me fix this before users encountered it.

The correct solution for us would be to detect the servers misconfiguration and raise a setup issue asking the admin to resolve.

You already gave one @chad, on Ubuntu if the sysadmin uncomments that section, then any link starting with .ht would be blocked.

Also, we link to . files elsewhere in Phabricator, so if we change Project URLs, this webserver config would still break other parts of Phabricator, like linking to .gitignore in your repository.

This is what I see on Ubuntu for default conf files for nginx, it's both commented out and restricted to .ht:

It is extremely common to have nginx configuration

Ok, I was able to add the user to the project by adding him to one of the subprojects. I guess that works for us. Thanks for your help.

Oh, I totally misunderstood what you said.

I have also archived both subprojects in an attempt to workaround this and I still can't add users to the parent project.

Both subprojects are set to "All Users" for their permissions

I still can't add users to the parent project though

I was calling it a zombie because I couldn't join it or change any of the settings on it even though it said I had permissions to do so. Maybe not the best description.

What is a "zombie" subproject and how can we reproduce this?

Ok, I was able to join the subproject by setting permissions on the parent project to allow joining by "All Users"
I still can't add users to the parent project though

The original error message seems to be improved, btw, but I also seem to have a zombie subproject now.

Upgraded to 121e68e3 and the problem is still there

Oh and we're at 31984a78ee at the moment. I may run an upgrade here in a bit just to see if the newer version fixes anything.
It looks like any project with subprojects has the "Add Member" link grayed out.

Hi guys, any update on this? It looks like I can't add members to the parent project either so subprojects seems to be making a mess of things at the moment.

Interesting (and weird). Thanks for the update -- and good luck figuring things out.

Quick update here. We've found that adding FORCE INDEX (primary) results in 79.4ms in production even without the key_history index.

The issue you're experiencing is because you're out of date.

I've rebooted the Windows VM and haven't seen this issue in a few days. So we're good. Thanks for the help.

(That was a race, not me separately correcting the status, if it wasn't obvious.)

Truly, we have closed this task.

time well spent, @epriestley

That is a cool looking bug.

General questions about using Phabricator are best in Ponder or IRC. If this is actually a bug report, you must provide full steps that we may locally reproduce the issue. Thanks!

OK, after installing all the necessary extensions and changing the php.ini as recommended by phabricator everything works nice.

OK, I'm going to switch to php7 and see if it goes.

T9640 is tracking PHP7 compatibility. We haven't extensively tested Phabricator on PHP7 yet, but I believe several users are running it without any issues. We're happy to fix issues you encounter with PHP7 if you report them.

@epriestley that is from PHP 5.6.17

Is that output from the version of PHP with a problem, or from PHP 5.6.17?

The issue is not comming from missing php-extentions. mysqli was installed and present in fpm and cli so that was not the issue.
The actual function is missing, as @eadler said in the previous comment.