Reverted commit rP55a698a28a750017e787979a72dd125858997fa5 on our install and repository updates now work again.

I don't understand what that information has to do with this ticket.

In T11124#179972, @chad wrote:

On your local install or on Phacility test instance?

On your local install or on Phacility test instance?

In T11124#179970, @chad wrote:

You can either point Diffusion in your test instance to the URL of your SVN repository, or if it's behind a firewall and you can't, you can zip it up and add it to the Files area on Phacility and we can manually retrieve it for you.

You can either point Diffusion in your test instance to the URL of your SVN repository, or if it's behind a firewall and you can't, you can zip it up and add it to the Files area on Phacility and we can manually retrieve it for you.

In T11124#179967, @chad wrote:

We need the repository, not the database.

We need the repository, not the database.

I've already import the database dump file. The backup.sql.gz file is the result of ./bin/storage dump.

In T11124#179963, @chad wrote:

Google and Stack Overflow are going to be better resources for things like this, and we're not unfortunately. At least with those sites you can give specific details about what system you have and what you're trying to do, and can get the most up to date answer. All we're going to do here is the same thing, and charge you for our time. That's not great for anyone. :(

Google and Stack Overflow are going to be better resources for things like this, and we're not unfortunately. At least with those sites you can give specific details about what system you have and what you're trying to do, and can get the most up to date answer. All we're going to do here is the same thing, and charge you for our time. That's not great for anyone. :(

We don't offer this service under free support.

In T11124#179960, @chad wrote:

Its up to you to provide us a reproducible bug report under "free support". If you need us to do these steps for you, we'd be happy to, but we charge $1,500 an hour for this.

Its up to you to provide us a reproducible bug report under "free support". If you need us to do these steps for you, we'd be happy to, but we charge $1,500 an hour for this.

In T11124#179958, @chad wrote:

If you're willing you can just import the whole thing into the private test instance and we can inspect it from there.

If you're willing you can just import the whole thing into the private test instance and we can inspect it from there.

In T11124#179954, @chad wrote:

If you can isolate the bad commit and upload a version we can inspect on a test instance on Phacility, we can troubleshoot it further.

• http://phacility.com/
• Click "Try Free"
• Sign up
• Launch a "Test Instance"
• Report back to us if it does not import there.

This isolates any issues with your local copy of Phabricator vs. our hosted platform. It also allows us (with your permission) to privately inspect bad commits for underlying issues.

If you can isolate the bad commit and upload a version we can inspect on a test instance on Phacility, we can troubleshoot it further.

I upgrade Phabricator today.

Thank you. We will upgrade this weekend and report back.

Your versions above are over a year old. Sorry for not catching that sooner.

We don't support old versions of Phabricator. Per documentation we require all bugs and support requests be performed with a current version.

I've read through this article and I am unable to determine what the next step should be. I've already used the repository tool to reparse the bad commit but new commits all go into the same state. One thing to note, my version of the repository tool does not have an --importing flag.

https://secure.phabricator.com/book/phabricator/article/repository_imports/

https://secure.phabricator.com/book/phabricator/article/support/

I created the task, then changed the tags manually (selecting only the tags I felt necessary - also removing the BUG tag). Seems I may have found a bug with the bug tracker. ;)

That is, if you go to the Diffusion workboard, we give you a generic create form instead of a choice between the various normal create forms, currently.

You can file stuff without those tags from workboards, and maybe "Support Request" just got caught in the crossfire of typing every possible tag, so that's a legitimate-albeit-unusual pathway here. But I wouldn't expect the short-lived "New Support Request" form to be accessible any longer.

This tracker is for bug reports and feature requests, and we're surprised you were able to file something without either of those tags.

How did you file this task?

This has been live for some time and appears to have resolved the problems.

From the downstream, it seems like the problem may be one specific user wanting to add mirrors to existing repositories:

It's also vaguely possible that we'll add "suggest an edit" (ala T4104) in a generic way, then untrusted users could suggest edits and trusted users could approve them. I don't currently plan to build this as a general-purpose workflow, though.

Another thing to consider is that your worries may be entirely solved at a social level. Giving people access but reminding them to only modify 'safe' fields. If your users are somewhat trustworthy this is entirely reasonable.

I don't plan to pursue field-level permissions in any application. They were somewhat recently removed from Maniphest in T10003. That task discusses some of the complications that field-level permissions create in the general case.

Thanks for the quick turnaround. I'll see if the problem is fixed in 48 hours and let you know.

Thanks for the report! This should be resolved at HEAD of master, and promote to stable in about 48 hours.

That last part which I just landed hasn't been vetted in production for very long yet, but I think this all works now.

Strategy I'm pursuing (for Git) is:

The trouble is that that could sometimes give the wrong answer, because querying the Git URI is not the only way that arc itself finds the repository; for example, the repository callsign can be hardcoded into .arcconfig.

I think the only way right now is to get the remote uri, call repository.query with it, and parse that.
It might make sense to just teach arc which to output it's things in json.

After you created the second URI, you can switch the first one to active IO back, so there the error messages does not work:

Strange. I tried it again, now I can't reproduce it too, but the history said, that I didn't make a fault.

I can't reproduce this. Here's the first repository (I/O off, disabled);

(Although we do formally support and have documentation for the the "import, then make hosted" and "copy the whole working directory into place" methods of repository import now, both of which skip the pre-receive rules.)

Disabling Herald there only disables the post-push, at-discovery-time rules, not the pre-push pre-receive-commit-hook rules.

Hasn't this been done for a long time? In the current form on the page diffusion/edit/.../page/actions/ ?

This should be fixed in HEAD of master. Thanks for the report! Let us know if you run into anything else.

This should be fixed in HEAD of master. Thanks for the report! Let us know if you run into anything else.

Great, glad things are working. Let us know if you run into anything else.

Looks like that value was removed when the update happened as it was there before (checked with a backup).

Should be as I've only used SSH for the hosted repos - I will double check now.

Does your configuration satisfy the conditions described in the documentation?

If there's interest in prioritizing this directly or via T5000 I'm comfortable committing to an 80-hour estimate to support these use cases:

Thank you so much for giving me help here. Have a nice weekend. @avivey

It's based on git-grep. You can't give it any arguments.

Wow, that's great.

https://secure.phabricator.com/diffusion/P/browse/master/ - there's a Show Search button, that will let you search by filename or file contents.