In case it's helpful, these are my apache logs when trying to do a pull:

104.130.174.45 - - [18/Mar/2015:17:25:05 +0000] "GET /diffusion/API/konekt-rest-api.git/info/refs?service=git-upload-pack HTTP/1.1" 401 2384 "-" "git/1.9.1"
104.130.174.45 - - [18/Mar/2015:17:25:09 +0000] "GET /diffusion/API/konekt-rest-api.git/info/refs?service=git-upload-pack HTTP/1.1" 401 555 "-" "git/1.9.1"
104.130.174.45 - reuben [18/Mar/2015:17:25:09 +0000] "GET /diffusion/API/konekt-rest-api.git/info/refs?service=git-upload-pack HTTP/1.0" 200 1179 "-" "git/1.9.1"

There's (intentionally) no natural way to get to /repository/<branch>/. It's reachable by clicking the crumbs from /browse/<branch>/.

I couldn't figure out how to navigate to this page naturally, to be honest.

Why do you want to go to /repository/ instead of /browse/? See:

I understand, thanks for the clarification.

Yes,this is indeed a feature request.

Overall this sounds like a feature request, but I don't understand what /repository/ to you means in the URL.

I'm having trouble understanding your bug. Can you describe your current setup in more detail, for example what type of repository is this? Is this a feature request or do you think is is a bug? Does the issue reproduce on this server? Is your installation up to date? Can you provide screenshots to further explain your issue?

And the Subversion server is install over other machine, I'm not the administrator

I have add the ssl certs like "https://192.168.205.170/rZZH34382", but also have the same problem:

Take a look under the bold heading "Method": http://www.microhowto.info/howto/configure_subversion_to_trust_a_given_ssl_certificate.html

how to set phabricator host ignore invalid ssl certs?

Server SSL certificate verification failed: certificate issued for a different hostname, issuer is not trusted
Im pretty sure that is the issue, either connect over an unsecured connection, generate a valid certificate for the hostname, or have your phabricator host ignore invalid ssl certs

We could also implement a very sketchy version of this by maintaining an SVN working copy on disk and running normal grep against it. This is terrible, but maybe only moderately terrible.

Adding the file type to syntax.filemap worked for me.
Thanks for the quick fix!

• You can use syntax.filemap to configure how files are highlighted.
• The attached diff adds support for VHDL by default.

See additional discussion in T6516. This is not fixed until D11964. The root issue is a discrepancy between the web and Conduit workflows which I missed until it did bad things.

Those two patches should generally prevent problems here. With those applied, the behavior would have been:

Some related discussion in T6887.

Today Wikimedia Phabricator has been hit badly when we started importing the Phabricator repository (having forgotten about this problem). We stopped the import as soon as we saw our mailboxes flooded with notifications of commits and tasks marked as resolved.

Sorry, maybe this isn't a diffusion issue. The issue is with whatever the
URL takes you to which results from arc paste.

To clarify, you're checking files which contain ANSI color sequences into a repository, and then viewing them in the repository browser in Diffusion?

I believe this was fixed by rP8599145 and rPf6915a7. Specifically:

@epriestley: Any progress with the config?

We don't have enough information to reproduce this.

After D11050 and rPf33e2de09286 what work remains to be done to provide this? I'd love to see this completed.

Something changed an origin URL for me locally, but I can't figure out how it happened so it might have been a fluke and/or me being dumb.

bleh ugh yeuch

Adding T7378 here, any resolution of this task should include "diffs" in other applications as well (like Phriction).

Specifically, this isn't causing any problems yet (hg locate still works in modern hg at the time of writing), but at some point hg locate is presumably going to vanish and then we will have a problem.

Sorry, my fault -- I only gave the VCS user sudo access to the git binaries when I set things up. I'll update the config when I have a chance.

In T7339#98164, @chad wrote:

rHGTEST exists for you to test our server / repository for the issue.

rHGTEST exists for you to test our server / repository for the issue.

Yep, I think after my initial try with the commit right on the default (aka master) branch, which arc land apparently dispises, I think I mostly hit Mercurial specific issues (landing bookmarks and --merge not being supported). I created T7342 on the documentation issue to not derail this task here.

arc land --help or https://secure.phabricator.com/book/phabricator/article/arcanist_diff/

Almost. hg generates bad commits (using nano or not), arc generates good diffs (using nano).

So to summarize, hg and nano generated commits = bad. arc = good?

• Not using nano results in the same problem.

$ touch test
$ hg add test
$ hg commit -m 'Ümläüt Test'

We are going to set up test git, svn, and hg repositories on here for users to test diffs / commits against.

Actually, changing the largefile extension from being defined in:
/etc/mercurial/hgrc.d/hgrc
instead moving to:
/etc/mercurial/hgrc.d/largefiles.rc

We also utilize the largefiles extension as our repositories tend to have have numerous images, jars, other resources.

My mistake, I thought VCS password was referring to setting a password for the "vcs user," and then sharing that password with anyone who wanted to clone repos over HTTPS. I'm glad that's not how it works =)

Maybe I'm misunderstanding, but per-user auth is already supported via HTTPS (Settings > VCS Password). Each user gets a username/password. Or do you mean something else?

In addition to the things mentioned above, it'd be great if some form of per-user auth was supported via HTTPS. Perhaps this could be done by utilizing the existing user specific arc certificate, or generating a similar secondary certificate for the sole purpose of cloning repos.

To surface the details of D11827 here for future users, once that lands we'll begin using a heuristic to detect whether a push is an import of an existing repository or the addition of new commits. At the time of writing, the rule identifies a push as an import if:

Agreed on lack of value.

For posterity, see T6840 for the 99.99% issue.

I think the value of backdating feed is very small, and the current behavior is inconsistent anyway (not all commits get published). We could possibly consider backdating someday, but we'd probably want other use cases to support building the capability first.

@Mnkras, this is the issue you hit with the 99.9% repository.

This was fixed by D11102.