While I'm hesitant to throw stones here and don't really have any context on bundle2 or the wire protocol in general and there may be plenty of reasons that it works like it does, my general impression is that the Mercurial wire protocol is significantly under-designed, and is now on at least the 3rd and possibly 4th iteration of hacks to try to address the lack of actual protocol design.

I think the textarea predates using JS magic to make "copy" work. I think we could probably remove the "disable highlighting" mode now; I can't really imagine any legitimate reason to intentionally disable it in modern code, except maybe not realizing that "copy" will work correctly via magic.

Protocol for URI "svn+ssh://..." MUST be "svn+ssh".

what

That's too bad. I've done some testing and realized that the repositories that are exhibiting this behavior are non-bare, and one older repository that is bare is fully up-to-date in Diffusion's UI. (All are git repositories.)

@rfreebern Nope, no clue how to debug it. We just don't use Diffusion any more and instead use the Bitbucket page, whose UI we anyway prefer to see commits and browse the code :/

@adityar7 Were you ever able to resolve this? I'm seeing the same behavior on my installation, which we recently transplanted to a new server and converted its ancient file://-based repositories to hosted. My suspicion is that there's something not quite right with user permissions on the system, but /var/tmp/phd/log/daemons.log doesn't have anything useful.

It looks like the underlying issue (T11469) was resolved through configuration changes, so we don't need to go any further here. We are writing this log now, but it could use more work eventually.

I have pretty much the same "Status 126" issue on an Ubuntu 16.04 box with the latest openssh packages installed, following the instructions provided and modiying them for naming requirements. I'm running Phabricator on Nginx with PHP-FPM.

Differential also currently does not substitute a diagnostic message when declining to inline a patch: it should. ("Patch is too big to inline because limit X is set to Y." or similar.)

An additional inconsistency is that the diffusion.byte-limit applies to attached patches, but the differential.byte-limit does not. There's some vague argument for this behavior (you "shouldn't" be reviewing patches which are so enormous that they can not be emailed) but consistent behavior is probably better.

I agree that there is no sensible technical reason for the broken network policies that prompted my comment and understand your reasons for preferring to punt on a technical solution. Thanks for your thoughtful remarks.

(If the policy isn't fixable, you can personally bear the cost of this policy by tunneling the traffic over 80 or 443 locally.)

Have they asked network operations to allow outbound traffic on port 22? It seems like organizations which employ software developers should reasonably permit this traffic. Particularly, security-minded organizations should reasonably prefer asymmetric keypair authentication over HTTP password authentication in the general case.

Some GHC contributors have had some trouble with the fact that there is no choice in staging area URL. Unfortunately, some users appear to be behind corporate firewalls which block anything but http and https. We use SSH for our staging repository, which is of course problematic for these contributors. There are a few comments above from Nov 2015 which suggest that we aren't the only ones who have this issue.

Yeah, my problem is explaining to users what they should do, no so much with the actual blocking configuration. Although, if they do arc-diff and the only problem is my landing script not working, than I can special case it on my end instead of teaching them things.

(That doesn't solve the "engineers don't know how to initialize a new Git repository with git commands" problem, but I think that one's a bit more involved.)

I'm assuming the "empty" issue is that you have a rule like this?

The problem I'm facing is that users just don't know how to push code to a new branch; They expect to git clone a repository that already "works"; Commands like git remote or git push with any arguments are simply beyond the git-fu of some engineers.

If the major immediate issue is Herald disallowing branch creation with git push, we could add a Herald condition like "Repository is empty".

Another hitch when creating a git repo, is that it has no branches, which is confusing for less-advanced users, and very confusing if you otherwise dissallow git push; GH solves this by adding a README file to create a branch with a commit.
I think a more powerful approach is to support some kind of "templates", so that we can create a new "Android App" repo or "COM Module" repo directly, similar to how IDEs have project templates.

T11747 wants a more advanced version of this (reviewing diffs between rendered documents), although the specific document type it wants (IPython notebooks) is likely very complex to render.

Please see Contributing Feature Requests and Describing Root Problems for guidance on filing a valid feature request. You need to follow all the instructions in those documents before we can accept your request upstream.

Thanks!

Yeah, ON DUPLICATE KEY UPDATE is sensitive to order. Setup:

I think this is:

In T8238#196204, @epriestley wrote:

I'm a little confused about how these tags are appearing so widely in developer working copies in the first place. Is git clone fetching them by default? Do you have unusual default options configured? Do users regularly explicitly fetch all tags present in the remote?

That is, my expectation is that git pull does not "bring everything back".

In T8238#196204, @epriestley wrote:

I'm a little confused about how these tags are appearing so widely in developer working copies in the first place. Is git clone fetching them by default? Do you have unusual default options configured? Do users regularly explicitly fetch all tags present in the remote?

That is, my expectation is that git pull does not "bring everything back".

(The major goal of using refs instead of tags wouldn't really be to hide them per se, just to make them extremely difficult to fetch by accident.)

Maybe my assumptions about default behaviors are off, or the more-recent base tags (but not necessarily the diff tags) are getting fetched because they're often ancestors of master?

I'm a little confused about how these tags are appearing so widely in developer working copies in the first place. Is git clone fetching them by default? Do you have unusual default options configured? Do users regularly explicitly fetch all tags present in the remote?

In T8238#196187, @epriestley wrote:

I think cleaning up closed tags probably isn't a particularly great long-term solution since some fraction of the revisions likely just get left open forever -- so you'd have 500 tags instead of 50000, but I assume that still causes about as many problems, and you'll be back to 50000 in just 100 more years anyway.

I think cleaning up closed tags probably isn't a particularly great long-term solution since some fraction of the revisions likely just get left open forever -- so you'd have 500 tags instead of 50000, but I assume that still causes about as many problems, and you'll be back to 50000 in just 100 more years anyway.

We see how bad this is (does pushing tags to the same repository create a big user-facing mess?) and then go from there.

I clicked "Update Now" and the update frequency for our most active repository has dropped back down to 15 seconds.

This went out a while ago and I confirmed the fix in production.

+1 it's very confusing

We've been testing the LFS support for use with our game repository. Using a relatively small test repo we've had great results and will be going ahead and trying to use this for our main git repo (a new copy with an empty history that is). So thanks for getting support in! This is a killer feature as far as game dev is concerned.

Yes, if you want the change to apply retroactively. Something like bin/repository reparse --message --all rXYZ, but see bin/repository help reparse first to test that on a few commits and make sure it does what you want.

Ok, I understand.

There is no such setting, and I believe this use case is very unusual -- it's like putting the subject line of email in the first line of the body -- so I currently have no plans to add support for it (see also T8227).

I was able to reproduce on this install by passing rPf712ae718ccc1c94d882c626ca8626b77346026b to the Herald test console.

Part of this is likely a change to the semantics of setTimeout(). Current uses are:

Okay, thank you for the pointers, we have indeed a huge performance improvement using standard mysql replication, which seems to increase the queue usage.

I'm going to close this for now since I don't plan to take any further action as the upstream; this appears to be an environmental issue (which we don't offer support for) rather than a scalability limitation (which we do).

I'm not entirely sure, but it seems plausible. We compute "Queue Utilization" as basically:

Okay, seems bad indeed, do you think it might explain why the queue is capped at 20-30% ?

Yes, here it is.

Okay. Can you run this command?

Ah yes sorry, I saw some other reference to Nuance today and thought it was for that.

Oh, no, this is the right task. Your logs:

I think you may have answered to the wrong task :)

Someone has configured a bad Nuance source, so let's start by fixing that.

I added a note about this to T7338 for the longer term.