Software Engineering Lead
MIM Software, Inc.
Software Engineering Lead
MIM Software, Inc.
What if you try recreating the output generated by the hg commands shown from the --trace -- does the output look off in any way?
Any weird environment variables defined on those workstations? Also add --trace to the arc diff command might give more details
What if you disable the extdiff extension? The documentation doesn't mention modifying regular diff output but probably worth trying.
Hmm that wasn't creepy
I'll try to figure out more details/reproducibility for tomorrow, but through some combination of J+h+@ the highlight reticle will jump somewhere in the timeline
Err yea I didn't mean feedback as in "this is what I'd like to see" but more of bug reports. I did come across a bug but it's neither earth-shattering nor consistently reproducible.
Is this open for test/feedback (I think it's usually called "Errata" here)?
Please identify the versions of mercurial used on client/server, also the version of Phabricator in use. If you're on an older version of Phabricator it's possible that upgrading may resolve the issue.
only half of them :/
I think the phabricator pages typically have CSS for @media=print or whatever HTML is -- which means you can print or print-to-pdf and generally get a good result. I hadn't done it in several months, but trying it on this task it's a little narrow
I was fully expecting a black market for mana points to be available.
I've been terribly unlucky in locating fejolollololals in any grocery store here on the East "coast".
Also this should probably be using ui.status()/ui.warn() instead of print.
@epriestley - Just to clarify, with the solution you're suggesting that would mean the diff created using differential.createrawdiff → differential.revision.edit would result in arc patch of that revision applying the patch to the base revision parsed from the raw diff from hg log --patch --rev <rev>?
I tried to not specifically ask for a change to API or parsing, just that the missing bit I need is a base revision set on the new diff.
So by going through a Plan Changes status it would "clear" or "address" the prior Request Changes status?
Okay - wanted to double check
The revision was created on 56dd1b297c3e5cdbb477acc7435d6aa5749f33f2. While at that same revision I had updated the diff.
I'm not sure if what I'm seeing is a bug or expected (or even if related to this). We have sticky accept set to true (just as default).
I'm not sure if it would be informative or not but I captured the output. The larger/interesting ones I see are
OPTIMIZE Optimizing table "phabricator_daemon"."daemon_logevent"...
DONE Compacted table by 457 MB in 507ms.
OPTIMIZE Optimizing table "phabricator_differential"."differential_changeset_parse_cache"...
DONE Compacted table by 540 MB in 76,254ms.
OPTIMIZE Optimizing table "phabricator_repository"."repository_commit"...
DONE Compacted table by 156 MB in 54,999ms.
OPTIMIZE Optimizing table "phabricator_repository"."repository_commitdata"...
DONE Compacted table by 50 MB in 32,327ms.
OPTIMIZE Optimizing table "phabricator_repository"."repository_parents"...
DONE Compacted table by 28 MB in 33,999ms.
OPTIMIZE Optimizing table "phabricator_repository"."repository_path"...
DONE Compacted table by 44 MB in 28,318ms.
OPTIMIZE Optimizing table "phabricator_repository"."repository_pathchange"...
DONE Compacted table by 1 GB in 806,286ms.
OPTIMIZE Optimizing table "phabricator_worker"."worker_activetask"...
DONE Compacted table by 99 MB in 285ms.
OPTIMIZE Optimizing table "phabricator_worker"."worker_archivetask"...
DONE Compacted table by 1 GB in 963ms.
OPTIMIZE Optimizing table "phabricator_worker"."worker_taskdata"...
DONE Compacted table by 4 GB in 1,109ms.
Also 9GB on production install, interesting
@eliaspro - I was considering adding it to our upgrade script. The process probably shouldn't be regular as it would likely degenerate response times while running.
No linux kernels~
Tried it out on our test install (~1/5th the size of our regular)
Completed optimizations, reclaimed 9 GB of disk space.
Woo! Should make backups a bit easier to manage~
If nothing's been typed in the text field for more than 5 seconds the user probably wants memes
Aha! That will simplify my dev setup/process
Please indicate the versions of mercurial on client/server as well as any extensions you have enabled on client/server
Thank you for explaining - I didn't mean to imply I thought it was a security concern, as it is very clear what giving someone Edit access means.
It sounds like the user is confused that having View access doesn't let them have access to decrypt/see the secret - only that they can use the secret within Phabricator. So in order to allow others to decrypt/see the secret he gives them Edit access which does give them the ability to change the secret.
is srs bsness mode taking over? i'm in a panic :[
FWIW I patched this locally and it fixes the scenarios I've seen this issue.
After updating the task a million times I did reduce the reproduction steps to just not having the user in the Default View Policy (presumably at time of creation the creator is not in the Subscribers policy group explaining the others' scenarios). I had updated the description to note that but I chould've made that much more clear. Spaces were totally a red herring.
@phillco - Is this for like, seeing code reviews that haven't had active participation in while? So users could see what's not being reviewed and lend a hand? Under the assumption that the "most-qualified" stakeholders (or Owners?) are already reviewers/subscribers of a code change but aren't being active, how effective would others' review be?
Thanks @chad for the help and motivation~
The key ingredient is to next set the default View/Edit policy of Maniphest to the Employees group (for Default Space which user is not accessible to)
what's your policy on supporting "random" PHP snippets from "sources" into Phabricator code
What is the best way to log something to the web server logs? I've been mostly using exceptions but that's proving to be more and more cumbersome.
I tried reproducing this on my phacility instance but I couldn't. Additional steps I took to mimic my setup were:
Maybe this should've been reported on T10004?
I am seeing this too. I've not confirmed 100% but I think it has to do with Spaces:
We ran the script provided above to get an audit of at-risk files. Afterwards we upgraded our instance and the upgrade succeeded however its attempts to delete the affected files failed. The failure is due to using a local file store which is accessible to our web service account but not the phabricator phd services account (T4752). After correcting the file permissions so both accounts have appropriate access, running upgrade again doesn't seem to remove the files.
Tried again with node v6.9.4 (current version of node with CentOS7), and still has same problem 😢
That's a good point about also accumulating any security notes
Asking someone who is say, 16 months behind to read 80 changelogs seems detrimental to having people keep up to date.
This is partly why I would like this -- the Upgrade / Compatibility section of changelogs is probably the only near-mandatory sections to review before upgrading (things might behave differently until you do databasey things, the way a configuration behaves has changed, etc.). My process for upgrading right now begins with reviewing the changelogs to make sure I don't miss any pre/post-intall steps, and I'd like to automate part of that if possible. For a site that's upgrading weekly this isn't a challenge, but sites that are unable to upgrade as frequently would (should?) be sifting through this stuff anyways. I think this would be part of community resources and not officially part of Phabricator.
Did I really have an extra space in the title
Different parts of the repository page may or may not load indicating error. I refreshed on the page with the commit a few times and sometimes it says the commit is missing and other times it can't load the content, and other times it can't load the paths, but sometimes it can load them.
I'm good with the current balance of the changelogs - the one thing I think would be nifty is being able to accumulate the Upgrade/Compatibility sections across changelogs, for sites that aren't able to upgrade weekly. I was considering making a script to scrape that info but haven't had a chance to sit down for it. Also it'd be relying on the changelog format to be consistent (seems to be pretty darn consistent).
I tried removing white space: nowrap; (from one of .phabricator-action-view button.phabricator-action-view-item, .phabricator-action-view-item) in the browser inspector on FF and it looks like it goes back to normal (even when expanding).
Workaround is to URL-encode the parenthesis (%29) or use the remarkup style
[Back to the Future](https://en.wikipedia.org/wiki/Starship_Troopers_(film%29) [[ https://en.wikipedia.org/wiki/Starship_Troopers_(film) | Jurassic Park ]]
One use case for "locking" a task could be:
I like the idea of a feed/panel that shows recently active objects and not the individual events, but I don't know that I have a specific use case for it now. For how I use feed I think being able to filter out commits would be a nifty plus, as those tend to pollute the feed during arc land activity (and comments in tow). I don't think I feel too strongly about it right now though, as most of my work is driven via email activity and I primarily use Feed as a means of discoverability so I can poke my head in if something sounds interesting~
Add catfacts tooltip to each application?
Not a big deal since it'll be a while before any install has enough badges for it to matter.