I don't see any error trace in my web server logs (/var/log/apache2/error.log, /var/log/apache2/other_vhosts_access.log). I may have been unclear in my description: the error message appears at the top of the Diffusion commit page, but the page appears to work fine otherwise. It seems as if Diffusion is generating an error and catching and showing it but is otherwise working fine.

This install is giving a different error: rSVNTEST3:
svn: E155007: '/core/lib/phabricator/webroot' is not a working copy

rP0db86cce7d was recently landed, you could check it that's the culprit by reverting just that commit. I presume you're pulling HEAD and not Stable?

Can you paste the full error trace? It would be in the webserver's error log.

1.8.8 (as shipped with Ubuntu 14.04, in case that's relevant).

What specific version of Subversion are you using?

Not as an upstream solution.

Would stripping the tags from the md file during rendering be a solution? It would be sufficient here...

There's no way to do this. It would allow anyone with commit access to XSS other users and take over their accounts.

I believe so? Maybe only some clients do?

According to http://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html

403 is access denied, which Git clients treat as "bad credentials". When the repository is disabled, there's no credentials which will make the check pass.

Oh, I guess there isn't actually a "test plan" Herald field. We could add one easily enough. I was thinking:

Either Phabricator should allow pulling from Inactive repositories (I see no reason to prevent pulls, but preventing pushes is probably reasonable),

In T9331#138095, @epriestley wrote:

Workarounds like the one above (or just writing similar Herald rules) seem reasonable to me, if not ideal.

I frequently use backticks in task/revision titles and would like for those to be rendered as monoscoped text, but this is a relatively small use case.

What status code do you feel is more appropriate? 403 seems quite reasonable to me.

I don't currently plan to try to let fields be configured per-repository. This would be a lot of work to accommodate a fairly rare need, require substantial workflow changes, and doesn't seem to be particularly valuable. Workarounds like the one above (or just writing similar Herald rules) seem reasonable to me, if not ideal.

I think it's probably correct for task titles, Phriction document titles, etc., to not be Remarkup.

It might become possible after T731, but this is a very rare need and not a good fit for the upstream except as part of more general changes in T731.

Cool, glad things are working again.

Also, we certainly disable and re-enable users occasionally, so hopefully that will continue to be a supported use case.

@epriestley, I got a flood of emails starting at 1 PM, thanks! I'm not aware of any further issues with this.

The queue has flushed so I think this is now resolved (there are no longer any publish actions backed up in the queue), can you let me know if you're still seeing issues when you have a chance?

I've deployed this to repo001 (where this instance's daemons are located) and the queue appears to be flushing. I'd expect that you'll start receiving missing mail shortly (there are about 100 affected commits in the backlog). I'll follow up in a few minutes once things flush or otherwise stabilize.

Ah good point. I keep learning!

Public (No Login Required) is the name of the Policy control. I think it's more clear to use the exact name vs the short name.

I'm a complete noob to phabricator but I'm loving it! Found this while setting up my own instance. This is obviously of little to low priority but thought I'd drop it here just in case. As mentioned my skills are low with phabricator so searching Maniphest might have failed me if this is a duplicate.

@argylelabcoat - The last comment made by @epriestley is describing the use case of @bcran's need for the Blackbox extension available for Mercurial. See T9393 for their discussions. This task is a generic task for providing some support for Mercurial extensions in general. He was just relaying a summary of the conversation.

The use case I was trying to accommodate was source control for projects with large binary files -- often multimedia files of some sort that get updated and integrated into a complex build process. Presently, SVN handles this better than HG or Git unless extensions such as hg largefiles or git-lfs are utilized

D14096 has some screenshots of this and I've pushed it to this server. It may get some design followup but feels relatively reasonable to me in its current form.

T9393 discusses the "Blackbox" extension. To summarize:

Cool, that sounds reasonable. Broadly:

Since I have a workaround should I close this? Or, since my system's using Mercurial 3.5.1 should the code be skipping the workaround for older versions?

Yup, I understand now: we enable the extension system-wide, so I'll update the hgrc in Phabricator's clone of the repo with "blackbox = !" to disable it.

Can you just disable the extension for Phabricator's copy of the repository?

In T9393#136524, @epriestley wrote:

Why are you interested in running this extension?

The erroneous revision is because when hg log is invoked with --debug, it prints arbitrary messages to stdout which we can not distinguish from log output.

Why are you interested in running this extension?

The person who reported this is no longer around to provide more context.

This should be resolved by D14092. Thanks for the fix!

@berenm suggests what is likely a simpler fix here:

D14092 is a patch that doesn't require to store the password as clear text in the hgrc.

No.

Is this related to T8936? I.e. similar cause?

We do not currently support git notes, and I had never heard of it before this task.