As I mentioned over email, you'll have to update Phabricator before asking for help. That version looks at least 18-24 months old and there have been significant changes.

thanks

Please read Support Resources for where we take questions about Phabricator. This doesn't appear to be a feature request.

Thanks, I think D17097 should fix this. It isn't intended, and is just a curious artifact of some other behaviors.

cat is slow to appear

I see cat :)

ok now cat is in feed

hmm, cat no show in feed

It's doing it again now...

Okay, thanks!

Oh, I think the issue is this:

I also can't reproduce this:

It's fine to consider it not a bug. Mainly I wanted to provide the info that it doesn't work for documentation purposes, in case anyone else runs into the same situation in the future. (We ran into this by trying to transition from a very old Phabricator installation to a new one with hosted repos, but with a legacy deployment setup that needs a non-bare repo copy, and didn't realize that Phabricator didn't fully support hosted non-bare repos.)

Why do you consider this to be a bug, then?

No.

Do we tell you to do this in the documentation anywhere?

This is a billion years old now -- see, e.g., T11954 for more modern work.

"Blame Revision" was a freeform text field at Facebook (from before DiffCamp, even) where you were ideally supposed to enter the revision or commit that introduced the bug you're fixing, if you were fixing a bug introduced by some known change.

I expect our forking to be much lighter-weight than GitHub's (ideally, I'd like it to work something like git push whatever/branch creates a fork called "whatever"), forking is just a familiar metaphor.

In T11535, @samking says forking "seems like a fairly heavyweight solution," and that users don't want their own GH-style fork as much as they want to create branches "somewhere".

I upgraded my installation to

commit ad65d933fa75a2c417ba23f3684f0109de0f6ace
Merge: cfcc3b8 f0bf041
Author: epriestley <git@epriestley.com>
Date:   Sat Dec 3 02:39:57 2016 -0800

Damn, that was fast! This should be a perfect solution - thank you for your help.

@epriestley Thanks, that's fixed it! I'd not looked index engines at all before, so wasn't sure if I was just missing something stupid on that side.

I'm pretty sure this this was just a straightforward fix that escaped detection for this long because any other repository edit would rebuild the index. D16972 rebuilds the index on any repository URI edit. Let us know if you're seeing issues after that. Thanks for the report!

Does making any other edit to the repository (e.g., changing the description) correct the issue?

OK, this is interesting: having tried reproducing it on a test Phacility instance, it works as expected there. Perhaps one difference is that my local installations don't have Diffusion serving repositories itself over, e.g., SSH? These repositories do not have any URIs other than a remote Git URI which Diffusion is observing.

Heh, just ran into this today

No, there's no specific support for LFS mirroring yet.

This doesn't add any compatibility with mirroring, does it?

It works, thank you!

We have the same issue after the last update and we usually update once a week. I can confirm that the issue happens with any commit to a SVN repository that you want to view via Audit. Git commits display fine.
Might this be related to the change "Old", "New" and "Diff" tabs in the web UI from your latest changelog?

To answer @avivey's question more directly, it takes a long time for the yellow Loading... bars to expand to the diff for files I'm interested in because the server is spending all it's CPU time generating diffs of generated files that appear first on the page.

It's true that they're loaded in parallel using AJAX but there are enough generated files that it's tying up the server's CPU. And the generated files seem to end up first in the queue.

FWIW: I believe @paladox means well, he's just young/inexperienced and overly enthusiastic. The decision to ban him is entirely reasonable for upstream though, given the circumstances.

The driving install dropped off the grid a while ago, so this is no longer prioritized.

This is sort-of-maybe related to T11482 but I'm also not exactly sure what's step in the process is slow here.

Which interaction exactly is taking a long time?

I'll have to update my instance first to test your patch, since it seems to be for newer version as you said earlier. I installed this from FreeBSD ports system, have to first convert it to normal git based install.

This self-healed (probably after another commit was pushed) so I don't expect to look at it for a while unless it happens again.

(mindrot.org is currently inaccessible for me so I wasn't able to read the details you linked, although I imagine they aren't too relevant to how we handle things.)

I'd prefer not to produce any output until we've generated everything, so we don't end up in a situation where we output half of the file and then fail if we can help it. Additionally, this script changed in D16744, a few weeks ahead of your version.

As a user of both Phabricator and Mercurial, opening up HTTP isn't an option we want to consider and would instead stick to having the repository hosted elsewhere.

Today, we already decode the SSH wire protocol and figure out what's going on inside it up to the bundle2 stuff -- here's the, uh, "protocol spec":

It should be possible to determine whether an operation is read or write by the command name: a command either performs writes or it doesn't. The only write commands you should see are unbundle and pushkey. While it might be possible for batch to contain pushkey operations, I don't think that's done today (but I'd have to audit the code to be sure). One thing you should be able to rely on is the HTTP method: GET requests should never perform any significant writes (although some cache files may be written to as a result of resolving data, but that shouldn't be important). It should be perfectly valid to treat GET and POST differently. Although if you route requests to different endpoints within the same TCP/HTTP stream, inconsistent state of a read-only mirror from a master could lead to race conditions (e.g. push fails because a mirror is out of sync). If you route by HTTP request method, you should not need to know anything about the Mercurial wire protocol.

@indygreg - Thanks for reaching out and discussing a way forward. I am not on the phabricator team but I do have an interest in its integration capabilities with mercurial. At best I might be able to summarize my understanding of some of phabricator's needs based on the history of this task, but I do not feel I could properly represent them on mercurial's mailing-list or wiki. For hosting repositories I believe this task would require needing to know if the mercurial operation is read or write -- the two primary reasons being read/write access control and cluster picking.