Have a most recently accessed repo list in there somewhere. Right now the order is always listed by most recently updated repo shows at the top. Maybe a additional column in there that shows most frequented repos? or maybe a "favorites" list for repos. A user can have access to many repos but not use them frequently, so pushing them towards the bottom.

In T12804#226290, @sascha-egerer wrote:

T8442 would help a lot for those "I have to many repositories"

GitHub, which has an omnibox

I find it really annoying how there isn't a real repository search (grep files) before you go click on "Browse". Generally speaking, search in Diffusion is very confusing with three different search fields in comparison to GitHub, which has an omnibox.

I queried the production backup log to find the maximum size of any active instance's backups to contextualize decisions around backup and storage management in D18094.

T8442 would help a lot for those "I have to many repositories"

Comments are fine.

Clicking "Cancel" after starting an inline comment leaves "0/1 Comments" in header. (do you want tasks or comments for these issues?)

Conveniently, bin/restore already exists and does much of the above, although it doesn't have a --download flag yet and its current behavior is to abort if data already exists.

Actually, from the logs above I didn't even do it manually and just made it up for no reason.

Thinking about this a little more, there's really no reason to do any of the rebinding stuff until after we move the data. I did that earlier when moving manually, largely for convenience -- but we don't need to sequence things like that when automating, particularly if we don't need bin/storage to work on the new database.

I think we have a generally tricky situation on the database stuff here. The general algorithm this process is using so far is:

This is because of the synthetic comment from Lint near line 108 of DiffusionHistoryController.php, not because of the comment in the screenshot.

(That said, GitHub does show an accurate count so who knows. Maybe the page is slow because they aren't doing anything stream-oriented. In this case, a directory with 3M files probably just crashes.)

I also suspect that GitHub compromises here for performance. If you look at a very large directory on GitHub, it shows only the first 1,000 files fairly slowly (page takes 1-2 seconds for me) with no pager, and a warning that the directory is too large:

The reason this isn't trivial is that we ask git, hg, or svn for a list of files, for example with git ls-tree.

yes I believe you have been coaxed into a clever trap -- and your predicament is of your own making!!!

Please see Contributing Feature Requests for instructions on how to file a constructive feature request.

This will help

I’ve been catfished.

Yeah I just realized this isn't a front end change, I got to trace it down to the source.

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.

oh

👍

(Poems doesn't have an example of the first kind of directory, and I don't know of any offhand, but you could build one locally in a couple minutes I think.)

Offhand, I don't know if the kernel has directories with a lot of files in it or not -- like, Phabricator itself probably has only 1-2 directories with more than 100 files (resources/sql/autopatches/) and might have none with 100+ files and directories, so you could implement this wrong (pick the first 100 paths, then sort them by "directoryness") without there being any counterexamples in Phabricator. It's possible the kernel is the same.

Is poems the best example or do you have another suggestion? I can try the linux kernal.

Or, specifically, a list of files like this:

(That is, more than 100 non-directory files.)

I don't care too much.

@epriestley Do you care if I just flip this. The hypothesis being folders are clicked more than files, and having them first makes more sense for me, and in our case, brings them above the page fold currently for rP.

I'd probably pass on the preference, I think folders should just go first. My main observation here is if you instrumented clicks of folders vs. clicks of files, folders are probably chosen 2-1, my expectation here is that people have to dig down first, then open the file they were looking for.

In T12144#226158, @epriestley wrote:

Why would you want to set those up as milestones instead of subprojects?

It doesn't help that GH/GL Milestones are loose tags with a target date.

We could also let you collapse/expand columns like your mock in T6642. None of this hide/show/filter/collapse/expand stuff is hard -- T11036 and T4900/T10336 are the only really involved JS changes in queue for workboards, I think. It's largely just not clear to me which subset of the proposed tools is most useful, and it feel like major overkill to implement all of them.

But it's mostly moot until T11036 I think. T5024 is vaguely related ("filter to just one column"). T6642 might be related ("save collections of columns") but my recollection is that task was a bit muddy? I haven't re-read it recently.

That's very easy, just a question of whether we want to add the buttons/menu items for it.

Yeah there are some UI tweaks I can do to dissuade accidental milestone creation.

What about workboard filters? View Milestones, View Subprojects? That sounds like a lot of work though. Might be nice on large parents.

One minor fix would maybe be to put "Create Subproject" first on the "Subprojects" page. This is inconsistent anyway -- the tab is called "Subprojects" and the header is "Subprojects and Milestones", but the order in the action column, the curtain panels, and the main panel is "Milestone, Subproject". I think this stuff blame to me in D15152, but "Subproject, Milestone" is probably a better order both for consistency and to gently nudge users toward the more general / less specialized unit of project division.

I don't think this should be a language problem or that "Milestone" should communicate "flexible target" -- physical milestones are big, immovable, evenly-spaced chunks of stone with a single increasing integer chiseled into them. They're a really direct metaphor for the behavior of milestones as implemented in the product. But feel free to send me a diff to swap it to "Iteration" if you think that's clearer, I'm not married to "Milestone".

Maybe it's a language problem. "Milestone" to me says "target" so I think it's a fluid set of targets that may or may not be in an order.

If anything, a hypothetical "Progress" tab should show ALL subprojects and only a SUBSET of milestones: just the last, current, next, and maybe +2 / +3 milestones. If your work is really linear and time ordered the progress of the milestone from five iterations ago isn't relevant most of the time.

That is, milestones largely exist to support future features that depend on a linear ordering, like "push all open tasks to next milestone", automatic creation of the next milestone from typeaheads, automatically scheduling milestones sequentially for charting/reporting, etc. If we let you reorder them most of that stuff sort of goes out the window (or, at least, gets much more complicated). And if these features aren't actually important, I think we could possibly just remove milestones from the product.

There's no technical reason we can't let you reorder milestones, but adding features that let you bind milestones to time ranges may be much more difficult if we let you reorder them.

I'm still ok with allowing people to re-order milestones, hard to imagine we'll get reports asking for it to be restricted.

I think that's conceptually reasonable, but I can't come up with any reason offhand that it should be restricted to milestones instead of showing both milestones and subprojects.

I was considering building a formal "Milestones" page which listed all the current milestones under a parent and their respective progress.

Yeah, I'm pretty sure there's no difference.

What behavior do milestones have that subprojects lack (or vice versa) which is relevant for progress tracking?

Oh maybe I forgetful. Anything can track progress.

Because they track progress.

Why would you want to set those up as milestones instead of subprojects?

@epriestley do you still feel strongly to not do this? I presume it's just gated and easy to ship.

(None of this impacts anything outside the ops realm in any way, except that some of the admin/ops-flavored UIs are changing a little.)

There will be a final written exam on June 19th.

Just to clarify, it's ok that I'm not following, nor understand any of this, correct?

Oh. My. God.

(Slightly related: I killed the test-nat instance this morning since it doesn't help actually test the NAT).

Er, that was rCORE085cd7e4 but I typed D instead of T.

I inched us forward on getting EC2 and Almanac to agree with one another, but need T12414 to make much more headway:

I can't reproduce this. Here's what I tried:

It doesn't try to run evil.exe until I edit the cell (the csv version, and the modified xlsx I saved myself try to start on opening).

Here's a version with =cmd|'/C evil.exe'!A0 if that produces different results:

Actually, Excel 2016 is vulnerable. The test case is incomplete. The cell needs to be =cmd|'/C evil.exe'!A0 to trigger the issue.
By modifying the value in both the xlsx and csv files, I was able to blindly click yes on lots of warning prompts and start calc.exe. But I am not sure that modifying the value in the xlsx file is giving the same result as the export would (something may have been stripped off in the meantime...)

It seems an up to date patched Excel 2016 is not vulnerable.

Saving this file as csv also doesn't trigger the bug in Excel 2016 - on reopening, Excel misdetects the format as SYLK, warns about the extension not matching, then warns that an error occured during loading, and finally when you agree to continue loading as "a different format", it opens without running calc.exe or prompting to update cells.

Some of the syntax has changed slightly from the above, but I think the overall plan remains basically correct.

phage remote status --pools db,repo and such work now, using Conduit credentials from the bastion to query admin. We can swap that stuff later if we want to switch to EC2.