This will be available in a future repository.search method, via T7715. See here for some discussion:

We had only imported one repository when we saw 0.00% progress and nothing but errors on the logs. I'll delete the database and reinstall Phabricator, this time with just our dummy test project to see if it finishes importing.

By importing repositories, you have amassed a large number of commit import tasks. By deleting those repos, you've made all these tasks obsolete, and they will fail in this manner.
Your safest action now it to wait it out; You can increase the number of task-processing daemons by running ./bin/phd launch 4 PhabricatorTaskmasterDaemon, and let them clear out the bad tasks.

Indeed, there's nothing there by that ID - but why?

Your SQL is wrong. It should be:

SELECT * FROM phabricator_repository.repository_commit WHERE id == 77039

Is the Phabricator query wrong then? I've tried loading the commit data based on the commit "id" value rather than "commitIdentifier" here:

commit_id is the id column, not commitIdentifier column.

There's no technical reason for that, either, although it probably doesn't make sense to raise it in advance of just fixing this properly.

On the flexibility side of this I've managed to run into the 32 character callsign limit. We like long names? ¯\_(ツ)_/¯

Just an update:

Hi this files.viewable-mime-types doesn't seem to apply to desktop since testing using an iPhone 6 plus using safari and using a windows 10, edge and internet explorer the iPhone seems to register files.viewable-mime-types and follows what ever is set in it but on desktop it doesn't since for example going to https://phabricator.wikimedia.org/F3069835 on iPhone and then click download it lets you view the raw without needing to download but doing the same on desktop doesn't it downloads the file instead of viewing the file in raw.

I can't reproduce this. Here's what I did:

@fanis Thanks for ur reply. It's not the reason of the problem. And it is quite weird that this problem will always exist with my test svn, but with my online svn which supports http it works fine. I don't know if there is something that do not support phabricator+svn solution (each of them works fine before combination) and no people including the contributors are aware of this.

I just realized after testing a few versions that the "Auditors: <username>" in the commit message needs to have 1 empty line before it to be triggered. Probably some parsing issue.

Well this is a feature request not a bug request. There is no problem. This feature would be really useful for users that want to download the whole repo for reasons a user may want to upload the files to his or her server doing git clone will take a few minutes because what if the user doesn't have any software that uses git to download the repo. It may take longer if the user doesn't know how to use the software and how to use for example git clone.

Hi please support downloading zip files or compressed files in differential and diffusion.

More specifically, this request is competing with thousands of other tasks vs. 2 developers. If you can't describe a problem this solves, then we can't give it any priority, and it will sit for many years. It's to your benefit to explain the entire use case to us in a manner which we can understand it's impact on all Phabricator users.

"Gerrit has it" doesn't describe a problem to us.

Well so that users could just like download zip files not needing to have git or any other program to be able to download the files. Gerrit support this and Wikimedia is moving to phabricator soon.

See Contributing Feature Requests. We need and want to understand root problems, and don't consider "feature doesn't exist" or "it's something we'd like" a root problem. Specifically in what scenarios are you distributing zip files in a repository why do they need to be downloadable by non-developers?

Your welcome.

Ok, I got it working. I'll add a tutorial style answer on another more suitable thread, and I am closing this for now.

Ok thanks a lot and sorry for the confusion! I shall start again from scratch, and post my findings here if I manage to run the phabricator's sshd on a custom port.

So please follow the guide from start again, then i or someone lese will helps debugging the "normal" stuff failing like permission in sudo, or git-executables not in path.

On http://phabricator.example.com/config/group/diffusion/ theire is all stuff you wanna configure ! In peculiar the ssh-port, the ssh-user ect.

Thanks a lot for the elaborate reply! No, it doesn't throw any such error. I get straight shell access to my server.

because we have tooling which relies on the regular SSHD daemon being available on port 22. And thus, I have to add the remote like above.

We haven't seen other requests for this and I think putting administrators in a project and using "Pusher's projects ..." is a pretty reasonable workaround. This can also now reasonably be written as an extension.

I am getting the exact same issue.
I am prompted for a user id and password so I use the appropriate ones:
user: user_name_in_phab
password: users_password_in_phab

• I believe username association works correctly.
• Assigning an email is already mandatory when creating a bot:

My bad, I didn't activate the option serving this repository over HTTP!
This wasn't a bug at all it's just I didn't ready the instruction carefully.
I missed this line:

Make sure you've added an SSH public key to your account. You can do this in Settings → SSH Public Keys.

Authentication Failure
This Phabricator install is not configured with any enabled authentication providers which can be used to log in. If you have accidentally locked yourself out by disabling all providers, you can use phabricator/bin/auth recover <username> to recover access to an administrative account.

Voilà ce que j'obtiens en faisant un clone.

Cloning into 'testrepo'...
* Couldn't find host phabricator.vonji.fr in the .netrc file; using defaults
* Hostname was NOT found in DNS cache
*   Trying 62.210.236.42...
* Connected to phabricator.vonji.fr (62.210.236.42) port 80 (#0)
> GET /diffusion/TR/testrepo.git/info/refs?service=git-upload-pack HTTP/1.1
User-Agent: git/1.9.1
Host: phabricator.vonji.fr
Accept: */*
Accept-Encoding: gzip
Pragma: no-cache

In the Google codereview app when it used to be possible to submit a raw diff for submitting code for review, it was quite simple to do that. The main issue is not the revision, the main issue is the path. So simply add a field in the submission form to provide the path to the root of the patch.

Then please follow our bug reporting guide: Contributing Bug Reports

I am asking phabricator. Since viewing raw php files doesn't work on deskop or laptop. So I am not sure what to set.

@paladox who are you talking to, specifically, the upstream or Wikimedia?

Hi the workaround works for mobile devices not desktops and laptops.

I can not reproduce this. Here's what I did:

For what it's worth, we have a very similar setup (40ish repositories in Phabricator, all hosted in Gitlab). We have not observed any performance issues such as those described in this ticket.

Since we don't have access to whatever GitLab is measuring, we can't understand this issue in greater detail. Particularly, we can not reproduce the underlying heavy load in a way we can examine. We have not seen similar reports from other users, except @jcarrillo7, who has not filed any details. We have many installs with hundreds of repositories and my expectation is that the operation is cheap, so I suspect this may be an issue unique to GitLab.

Sounds like you could easily fork and change the polling frequency; The calculation is at https://secure.phabricator.com/diffusion/P/browse/master/src/applications/repository/storage/PhabricatorRepository.php$1527, and you can drop it to an hour just by changing that line.

I am not sure of the underlying implementation of GitLab, but our phabricator instance has been flagged as the #1 user of GitLab resources. Our GitLab instance hosts thousands of repositories, so being the single largest user of GitLab is concerning since we only have ~50 repositories.

huge amount of traffic

At that scale, is there any reason to not use Phabricator's repository hosting instead of GitLab? You can mirror repositories from Phabricator to GitLab if you still need some GitLab functionality (see the Mirrors option under Edit Repository).

Oops! Thats embarrassing. These numbers were gathered from multiple places/multiple people, and mass confusion ensued. The 2Hz number came from the total requests to GitLab instead of requests per repository. Ill update the title/description accordingly.

I'm not sure I understand your math -- here's what I get:

@epriestley I know you mentioned that a diffusion.looksoon would trigger this, but we have no known users of this command.

This should be fixed at HEAD. Let us know if you run into anything else.

I was able to reproduce this easily by following your instructions. We'll get this fixed. Thanks for the report!

In T4245#144469, @joshuaspence wrote:

This is the only thing that is blocking me from migrating all of our repositories from Gitlab to Phabricator. Is there a clear path forward here? If so, I could potentially work on this.

This is the only thing that is blocking me from migrating all of our repositories from Gitlab to Phabricator. Is there a clear path forward here? If so, I could potentially work on this.

No real consensus here, so not worth pursing any changes in the upstream.