+1 for not adding undo behaviour. I too avoid yellow undo bars by saving empty comments. Alternatively, I guess, you could put a "Permanently delete" link in the undo bar so with one extra click you could whisk it away (which actually would be easier than going through the edit, empty, save dance).

I'll add a link too, it's reasonable.

The problem here is the default for the default branch, when the user didn't set it explicitly. In a user perspective it's then hard to know there's this option at all. Some link to set the default branch from the error could be more clear, but I don't think that's a common in phab to do that.

I don't know, I'm confused today. I'll see if I can make this cleaner at least. Somehow. We depend a lot on having a default branch though, like picking commit crumbs.

I will ship my branch selector dropdown and make sure it works without a good default branch.

That is, my expectation when you have set "Default Branch" to "mmmmmmmmmmmmm" and visit the repository page is just:

This is what it did in March 2016: T3607#163684

Like, it's not a regression from the Diffusion re-work.

Am I right there?

I think the part that is tripping me up is this never worked, that is, if we had a bad default branch, basically that's all we rendered. We didn't also render a list of good branches.

I'm attempting fixing this right / long-term. I think I'm ok right now.

Where is the exception coming from?

Before we didn't render the table, so the link to visit said table as full screen, doesn't exist. I think I need... better fallback here.

The reason I took navigation away is we throw exceptions instead of error messages when master isn't present (or have no commits yet). Do you remember the reasoning there (using Exception)?

ok thanks for the nice and easy repo steps. I'll have something after lunch, got appt at 11

I believe the issue here is:

oic k thx

I think the minimum size is 2 hosts, in separate AZs, in one region. e.g., everything1 in us-west-1a and everything2 in us-west-1c, so that assumption is sound.

Are we going to let customers start with a single EC2 instance, or require them to have at least some form of HA? My plan is to always create the VPC/subnet infrastructure assuming that the customer will have a second AZ (and ALBs for example require you to listen on at least two different subnets).

Well, I'm half mistaken. What you're seeing is a bug.

(Oh, no, I'm mistaken.)

Removing the text and re-saving the inline comment is supposed to enable an Undo? Hmm..

That's supposed to leave an "Undo" bar, still want us to fix the bug?

(I can reproduce on this install)

I think I found a minor bug. If I'm fairly confident that I want to remove my draft inline comment I'll Edit → Delete Text → Save rather than just Trash - I think just so I don't end up with that yellow box that asks if I want to Undo.

Is good movie. I's recommending. 2nd after-credit scene was really surprising, well done and whole cinema was awestruck.

https://www.mercurial-scm.org/repo/hg/file/default/contrib/phabricator.py is a Mercurial extension that allows you to send a series of changesets to Phabricator by calling Conduit APIs directly. The extension is currently tailored for the use cases of the Mercurial project itself, isn't distributed with Mercurial, and may require Mercurial 4.3. And it obviously bypasses Phabricator's built-in Mercurial server. But if you are willing to live with the caveats, you may find it a suitable workaround.

In the refcursor table, our current autoincrement is at 312,036,016. This is only 7% of the way to int unsigned, but the fact that we've made it to 7% in 18 months might suggest that column should be BIGINT, unless there are performance impacts of that.

The feed story for this was x renamed this from to Sample

it might have something to do with appearance.

All my firefox tests, as expected, look like 💩 😦

The expected case doesn't reproduce for me

I think (?) this reproduces for me, too:

It seems like a bug in FF to me

Hmm I've tried on two separate OSX machines using Firefox and can reproduce

I still can't reproduce it locally. Tried colors, tried high-contrast.

kk

At least, change from 464C5C to 000 when using Default Mode (not High Contrast), caused the menu to appear in the same fashion as High Contrast

It's the color of <select>

I don't know, I mean, I'd like to understand what triggers it to look so much better, but it's not a regression it sounds.

So this may be invalid? @cspeck just had to turn on High-Contrast on the test install~

Disregard the different installs - I can reproduce on this install as well just by switching High-Contrast on/off.

The difference appears when using High-Contrast vs. Regular-Type

Errr I may need to investigate further - this install has the same "Mid-April" style using this same browser. I noticed this change on our test instance after upgrading to the latest. We don't inject any styles/js or anything so I'm not sure why that instance would be different.

If we think it's a CSS change, and not a FF issue, going to have to bisect for it. No matter what I do, I can't get that menu to look like that on Firefox.

Not particularly - I copied the select HTML into a "Tryit Editor" from W3:
https://www.w3schools.com/code/tryit.asp?filename=FHPUWOW4JNFN

FWIW, ours looks the same as every dropdown I can find on other websites using Firefox 54, Mac. Do you have an example site that looks like your "Mid-April" install.

See PHI11. This has material impact when using PhabricatorRepositoryRefCursorQuery to query landing targets, and likely impacts the logic in DifferentialRevisionOperationController.

I can't prove it but it feels like the new style is a bit sensitive to selecting an item -- sometimes when opening the dropdown menu the first item auto-selects and closes immediately. I can't prove it though.

I'll look at the pricing breakdown and I might do some perf testing just to see if there's any real difference.

If we're using ELBs for this (which it looks like we may be able to, per above?) I don't think (?) we can do any path-based stuff.

We've been experiencing this problem from time to time as well.
In our case between two Phabricator installations.
The internal one observing a repository from a central dev server which always works fine.
Then the internal phabricator has a "mirror" URI configured for the repository to push any changes to an external phabricator installation.
This mirroring fails from time to time with the same error others have posted before (Unable to identify the reftype of 'refs/remotes/... in src/applications/diffusion/engine/DiffusionCommitHookEngine.php:404). Sometimes i could fix it by simply deleting a remote branch that was no longer needed anyway.
I've added a dirty fix now by inserting a "continue;" at line 404 so that the parser in findGitRefUpdates() simply skips unknown ref types and still imports the changes instead of failing completely with an exception.
Though i'm not sure what kind of side effects i might have introduced with this.

22280->22280 for aphlict (or we could possibly use path-based routing on the ALB instead of opening up a 2nd port?)

This is pretty sad that this bug is still open. I haven't found a way to use Phabricator with recent Mercurial, so I'm sticking on 4.0.1 ATM.

We should enumerate all the ports we're going to open up so we can do the security groups sooner rather than later. My list:

Cool, that all sounds like it's roughly what I expected. Thanks!

Skipping questions where you have the right answer: