Looking T9080: Service-based repositories in Phacility cluster fail too abruptly if cloning fails this isn't fixed for me. Until the UI allows you to configure the repository, I don't think this should be closed.

This is the same as T1849 but I'm just going to merge that here since this one is sort of more complete, even though T1849 has a great screenshot.

We don't have enough information to reproduce this or otherwise move forward on it.

This is reasonable and straightforward, and I have some adjacent UI adjustments I'd like to try making concurrently. This is <1 hour and can slip in somewhere if approved for prioritization.

Broadly, the behavior of fields can not currently be dependent on the repository a revision belongs to.

Yeah, I'm planning to convert the "Clone As" setting to "optional, unique repository name" and use it as an identifier in URIs if it's set.

(I'm not sure if this is already covered in the discussion)

For your information, we have closed the original report of this task at https://phabricator.wikimedia.org/T75715 as Declined.

(This should deploy in the cluster on Saturday, give or take.)

You're also welcome to try pushing a large commit to this server (there should be writable test repositories available in Diffusion) to see if you can lock it up. If you can, it's likely that will give me enough information to understand and fix the underlying problem.

I'm not sure how to reproduce this. At HEAD at the time this was filed, the query UI looked like this:

This appears to be resolved. It's been in master for about a week without issues and deployed to the cluster for about 48 hours.

(For completeness.)

Empty repositories now show proper message.

I'm closing this as a dup of Q104; As a question, it has the same answers.

Thank you, problem solved. I adapted the webserver user in the sudoers file.

sudo: a password is required means you have not successfuly set up sudoers file, as per https://secure.phabricator.com/book/phabricator/article/diffusion_hosting/#configuring-system-user.

curl gives this output.

That looks like nginx is trying to connect to fastcgi, but fastcgi is not running. I'm not sure how to enable it, because I've never used this setup before.

I changed to nginx and now I got this in the error log.

Phabricator ignores the part after /T/ (The callsign) in the uri, so this is not actually a different test. Try
http://server.example.com/diffusion/NNN/not_existing.git

The lack of error message in the logs is odd. Are you using anything other than mod-php? Can you get any kind of error message to show up in the logs?

The message is the same if I use a repo which does not exist (T exists, not_existing doesn't exist => also raises Internal Server Error):

I checked the Apache error log file and there are no entries.

I don't quite understand the use case here... I imagine that importing repositories is something that happens very infrequently and so I think that such a change would have no effect most of the time. Am I misunderstanding?

In T9192#132389, @avivey wrote:

Maybe rename the edit page "advanced" or something, and let anyone with "can view" see it?

I agree with you, the documentation is pretty good.

Follow docs - those are VERY good, well written and easy to follow.

Another thing is that I am running it on a new environment. I also tried to test a SVN repo but got another issue with svnserve, which is in the PATH, but Phabricator can't find it

You would receive a setup warning if you were using an unsupported binary.

Are there any recommended versions for GIT and SVN? Maybe that is the case.