This is now in stable, and deployed here and to the Phacility production cluster.
- Queries
- All Stories
- Search
- Advanced Search
- Transactions
- Transaction Logs
Advanced Search
Sep 25 2017
Sep 15 2017
This is now deployed on this server, we'll see how it holds up. It won't promote to stable until next week, and I'd discourage anyone from picking it up right away.
Sep 14 2017
In Mercurial, can a branch have some open heads and some closed heads?
Sep 13 2017
See also PHI68.
Oh, yes, sorry, looked at the wrong tab.
Do you mean "follow up in PHI55"?
Sep 12 2017
This is resolved by the Ferret engine, which can execute all parts of the query logic in MySQL.
Sep 6 2017
Sep 1 2017
Aug 28 2017
Aug 24 2017
I'm not sure it's a bug. The error message was surprising; HTTP/1.0 500 Error 1: sudo: a password is required. I see a matching error message in Q261. The solution there seems to be allowing the webserver process owner to have sudo rights. I now found there are docs on the subject diffusion_hosting#configuring-sudo.
Aug 23 2017
If you believe you've found a bug in Phabricator, please follow the instructions in Contributing Bug Reports to file a report.
This might be useful debugging information:
>> export GIT_CURL_VERBOSE=1 >> git clone http://phabricator.internal/diffusion/TRACTORAPI/tractor-api.git Cloning into 'tractor-api'... * Couldn't find host phabricator.internal in the .netrc file; using defaults * About to connect() to phabricator.internal port 80 (#0) * Trying 10.11.45.21... * Connected to phabricator.internal (10.11.45.21) port 80 (#0) > GET /diffusion/TRACTORAPI/tractor-api.git/info/refs?service=git-upload-pack HTTP/1.1 User-Agent: git/2.14.1 Host: phabricator.internal Accept: */* Accept-Encoding: gzip Accept-Language: en-US, *;q=0.9 Pragma: no-cache
This doesn't work again.
Aug 22 2017
Somewhat related, if you have a disabled "Home" as your top item, we still show that regardless of the active dashboard below it.
Aug 17 2017
Aug 16 2017
It works great now with Windows + Chrome + German keyboard layout!
Aug 15 2017
Closing this for lack of feedback, feel free to resurrect it if you get back to it.
This isn't a bug; they aren't subscribers, and aren't listed in "Subscribers" in the right-hand column or in "Subscribers" in "Edit Task".
Aug 14 2017
The error truncating behavior affects also Diffusion > R > Status, where only part of the stderr is shown, making it impossible to debug the problem without hacking Phabricator:
ab@phabricator-1-vm:/opt/bitnami$ diff apps/phabricator/libphutil/src/future/exec/CommandException.php.original apps/phabricator/libphutil/src/future/exec/CommandException.php 59c59 < $limit = 1000; --- > $limit = 1000000000;
Aug 11 2017
Aug 10 2017
T12956 has another situation where letting MenuItem generate 2+ items may be bad: we want to let a menu item steal the selection, but it's muddy to implement if each MenuItem can return several actual views.
Thanks for the detailed response, I certainly didn't expect it.
I believe the location of the OOM is a little misleading -- the real problem is loadFileData(). This returns the entire file as a string, and will thus:
The new rules on reports are still in flux a bit and extra-muddy for Community members, but I'd generally like to move to a "report + review" model for community reports, something like we currently have for code review. So the general idea is that your bug needs someone to review it and agree with it (e.g., reproduce a bug, or agree that a feature request is a brilliant new idea that makes sense and would be appropriate for the upstream and completely describes a reasonable, generally-experienced root problem) before it comes upstream.
I think this is a real bug. Here's a more complete example of what's going wrong, why it's wrong, and how to reproduce it.
Aug 9 2017
I would open to accepting this as a bug report if I felt it was deliberately designed to work the way you expect, but was not (like a regression). Or if information was presented that all other repository viewers do it this way. Otherwise I think it's more 'nitpick' or 'feature request'. A cursory look at GitHub, seems they show the full diff as well: https://github.com/phacility/phabricator/commit/5c1e4488dedafda08684b33a8a4786cf687d2811
In T12959#230805, @chad wrote:In general are you aware we no longer take bug reports or feature requests here?
In general are you aware we no longer take bug reports or feature requests here?
In T12959#230799, @chad wrote:What does "mysterious" mean.
What does "mysterious" mean.
Aug 7 2017
Aug 6 2017
I can confirm this.
Doesn't seem to reproduce any more - I have no issue importing from another milestone. Presumed fixed, but if not, please reopen with more detailed reproduction steps.
Just launched a test instancepoo and everything seems fine.
I wonder if this OOM error can also be hit in other workflow though, given that it seems to occur in PhabricatorFileStorageEngine::getRawFileDataIterator.
Yep, agreed that the re-targeted proposal is a better solution... I had just assumed that this was a documentation oversight.
Aug 5 2017
The plan forward here is to correct the text. I will follow up with you on Discourse.
We require the "a revision's reviewers can always..." behavior. Please implement it instead of changing the text.
D7150 added this text ("a revision's reviewers can always...") and I said it "wasn't true but would be soon", but never made it true.
Aug 4 2017
Aug 3 2017
fwiw, I can't reproduce this on OSX chrome any more. going to go test windows in german.... wish me glück.
I retargeted this; I think the proposed solution is not the best solution we can find to the problem.
Aug 2 2017
We should probably just remove this workflow, it's not clear to me that there's ever any reason for anyone to run bin/files purge in the modern codebase.
Jul 31 2017
I'm seeing these errors failing regularly:
Jul 28 2017
The simplest way to approach this is probably to do double writes: start writing the new tables, switch readers over, stop writing the old tables.
Jul 27 2017
Let me know if that diff works.
I honestly can't get the cool looking macos dropdown on firefox no matter what I try.
Per above, this is not a bug.
This appears to lack reproduction steps, so we can't move forward.
What is the network speed of transferring a similar file (e.g., a 400MB file from /dev/urandom) via ssh cat <file>?
Per above, the decision to color the default state is explicit so this is likely just a design tradeoff in the short term. I can test things locally if you want to keep fishing.