Software Engineering Lead
MIM Software, Inc.
Software Engineering Lead
MIM Software, Inc.
This might not be totally related but
Also, I've noticed that when applying dependent revisions like this, it seems that usually all of the commits will apply cleanly (without prompting) except for the last one, which will always fail to locate the commit to apply on and prompt whether to apply to current working copy state. Based on what I think arcanist is doing I would expect all patches to prompt whether to apply to working copy (since all patches will be given new commit IDs) -- it seems strange that all will apply cleanly except the last one. Does that sound like a bug or am I misunderstanding what's happening? I can try to investigate/debug if you think it might be a bug.
For (1), it is expected to not apply bookmarks to dependency changesets that are applied as part of the patch issued? When patched one-by-one they would each obtain their bookmark.
For perspective we use commit hooks to ensure that commits made in patch releases must exist in upstream major release first before being allowed in the respective patch branch. We then utilize herald to notify a group about suspicious merges or commits.
Gah I searched "mockup email" not Pholio..
I got an email about the last update but the contents look like some of the content is not HTMLized properly
A common reason for this is that users treat git push like "Save Changes", and the remote has thousands of epriestley-tmp-fix-T123-tmp-bakcup sorts of branches.
I resorted to hg log -r "descendants('XYZ123')"
Hmm the history view on this install is significantly different than the one on mine~
I just came across this today, though I can't recall a time in recent history of it coming up previously. I was looking at a commit in history and wanted to browse through history at that point - if there was a way to jump to the commit history at the point from a commit, would've helped. In this scenario I knew a commit was made shortly after the one I was tracing and trying to locate - that doesn't happen often though.
I'd offer assistance with testing mercurial on a large repository - but the largest repository I have doesn't have more than ~50 items per directory (that I'm aware of~), so I don't think it would hit the stress points you're looking for.
Checked on Excel 2016 and it didn't run calc.exe or prompt for "update cells". Also checked on Excel for mac~
I also need a clock
literally no such thing as a star token
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 😢