You can already do some of this: "Land Revision" itself is added to the menu via DifferentialLandingActionMenuEventListener. You can use listeners like this to extend the menu.

• Once D15499 lands, this is available as a prototype.

The technically-functional-prototype code is live on this install, now:

(There is also a different type of cache from <object hash -> metadata> we could build in Git, but that's kind of a lot of work.)

In SVN, we can use a different icon because we have prebuilt cache of file types (and must have this cache for other reasons, and can build this cache efficiently, and SVN distinguishes between binary and text files).

Quick update:

There is a similar discussion in T7676.

The same problem here. I have a lot of 'pending' audits because I did the commit and audited it. They have an accepted label in audit list, but 'partially audited' if I open the audit. It happens also if I'm the only member in the project that is needed to audit.

One issue which we'll hit eventually is that git-lfs doesn't currently support pushing to remotes by URL, but we push to staging areas by URL:

No way for the upload API to say "no thanks, I already have that file"?

Quick progress update:

D15483 changes the constant to 47 (15 window size + 32 for gzip + zlib), which should accept and decode the broadest possible range of inputs. If this somehow breaks something, 31 (15 window size + 16 for gzip only) is probably the next thing to try. See that change for discussion.

We'll try that in our next upgrade. Thanks for the help!

Here's a diff to make bin/storage adjust always run ANALYZE on every table after it makes other adjustments, but I'm not really sure if that's actually helpful or not (e.g., from the documentation, it sounds like the good analysis can be immediately overwritten by a bad one in some cases?):

I think so. Sorry for the originally misleading claim.Sorry for the originally misleading claim.

In T10560#165431, @epriestley wrote:

Should we get rid of the <commitID, isDirect, changeType> key, then?

Well, the docs suggest not doing that:

Should we get rid of the <commitID, isDirect, changeType> key, then?

The discrepancy between staging + production is almost certainly caused by the size of the data.

You do not need to create a secondary index on changeId as that is the leftmost part of the primary key. The secondary index just points to the primary index where the data is stored.

The underlying cause of the slowness is because the stats were completely off in the production table (was showing cardnality of 18 for changeId).

bin/remove destroy gives you a huge scary red skull-and-crossbones ASCII art for good reason, and you're accepting that issues like this may occur when you confirm the prompt.

The problem was encountered when we have deleted the existing repository with audits because we wanted to include not just the trunk but all its branches. The thing was that the deleted repository in Diffusion was not the first one to be imported again.

Interesting (and weird). Thanks for the update -- and good luck figuring things out.

Quick update here. We've found that adding FORCE INDEX (primary) results in 79.4ms in production even without the key_history index.

Before I forget:

Adjacent work:

Various notes from prototyping:

Ah, you're right, thanks! I misread that page -- that does make Mercurial tags a lot easier to deal with.

In T1130#118470, @epriestley wrote:

They're a function of an individual commit instead of being a function of the repository as a whole, so we'd have to do a lot more work to support them (it's not meaningful to, say, "list all tags in the repository", as it is with Git), ...

Hrm, I'm going to do some followup with our DBAs as well. The performance numbers above were copied from the DBA analysis; however, when I make the change in production, rather than in staging, some of the behavior does not directly replicate.

I'll leave this open for now since the behavior still feels a bit spooky to me, let me know how things go once you get the key in place? If they're smooth, we can chalk this up to be being bad at MySQL.

I suppose the originally proposed key may be better than I think. I was imagining that it couldn't use the third part of the key (on changeType) but I suppose it actually can. I'm still confused by the UNION ALL behavior, but if the key's working on your dataset I think it's fine to add it -- it takes <1 second to add to our dataset, so even for large datasets it shouldn't be wildly unreasonable, even if we do find a better key later.

That's fine -- it looks like it's picking up the keys, I'm just not sure why it's then examining 303 million rows when it has the keys available.

to clarify: I removed the key I originally added

KEY `commitID` (`commitID`,`isDirect`,`changeType`)

was I not supposed to do that?

Hrrm, let me see if I can reproduce anything like that, that's totally bizarre to me.

KEY `cidid` (`commitID`,`isDirect`),
KEY `cidct` (`commitID`,`changeType`)

are the keys created

Hmm, weird. Can you show me the EXPLAIN SELECT ... for that?

That variant of the query is slow as well.

That key seems like it's probably not great for the OR changeType part of the query. If you still have the table handy and playing with it doesn't take an unreasonably huge amount of time, is this better?

to clarify

KEY `commitID` (`commitID`,`isDirect`,`changeType`)

I'm going to figure out what the state of large PUTs

This may make sense to at least lightly entangle with T4752, which overlaps in some ways.

To do an integrity check, it looks like we have to compute the Git hash ourselves.

As a general preface, this stuff makes me a little uneasy about LFS in its current state:

i ran into the same problem

Hi guys,
Same issue here!

If anyone else set up a cron job or similar to keep a staging area with a fresh master, you should be able to throw it away after users upgrade past T10509. That task has some details.

Aha! That makes sense, thanks for digging into it!

tl;dr: looks good!