We still need to be able to reproduce the bug locally.

@chad or we could use exec for windows and proc_open for everyone else.

@chad yes. But php wouldn't stop working like that because of the windows version unless it would.

Aren't you running a beta of Windows?

Could we add something to bypass proc_open since it seems to be a bug on windows.

Yep it is passthru proc_open(): proc_open(): CreateProcess causing the problem.

@chad ive tested it now on your test differential still same problem, I'm using revision https://github.com/phacility/arcanist/commit/57f6fb59d73994d90cd94143787424ce0fdbf73b so it would have failed with proc_open if I was to use the latest revision.

@chad I will test now.

Can you reproduce against our test repositories here? See rGITTEST

It seems arc land carn't find any revisions I created or wont create any.

@chad how do I get the Arcanist version.

Windows / Git / PHP / Arcanist versions would be a good start.

@chad what details do I give you about my envrioment, because it is setup the same as everyone else.

when I run arc land it doesn't detect the revision so I have to manually select it.

Understood, but we still need the details to be able to see and fix the bug locally. Without knowing how or why your environment is different than ours, we have no means of identifying and verifying a fix.

@chad the installer just installs the files it doesn't do anything else so all the files are from phabricator except from installer.

This is just way too far off the map as far was what we take under "Free Support" and "Bug Report". Specifically:

Use the windows installer https://github.com/paladox/Arcanist-installer-for-windows

@chad ok.

OK, I'll leave it open and wait for reproduction steps. Right now the steps provided aren't reproducing in my local environment. Please take the time to include full steps to reproduce, as if you were setting up a whole new computer to isolate the cause. This is what we'll be doing. Loading a VM with your same version, installing the same PHP scripts, etc, etc.

Hi, I have upgraded both tortoiesesvn(1.9) and phabricator (server+client) and I still get this error.
I have tried to understand what happens to that and I think i have found the problem.
the problem is that arcanist run this command:

We can't reproduce this and we haven't learned any new information in more than a month, so I'm going to close it.

./bin/search index --force --all fixed this,.but i'm confused how some random tasks weren't indexed and some were

In T10468#162641, @epriestley wrote:

which svn client do you use ?

If this depends on a particular client, you need to tell me that as part of your reproduction steps.

i saw you have the file on the same folder. can you try moving the files between differnt folders ?

That also works fine.

if it still working maybe we should upgrade phabricator.

Yes, we ask you to upgrade before reporting a bug. Many bug reports we receive have already been fixed. See Contributing Bug Reports.

which version of phabricator did you use ?

HEAD of master.

which svn client do you use ?

which svn client do you use ?
i saw you have the file on the same folder. can you try moving the files between differnt folders ?
if it still working maybe we should upgrade phabricator.
which version of phabricator did you use ?

Unfortunately, this bug is reproducible on my installation by simply visiting the Diffusion URL, there are no other steps.

I did look at the page.

This has been open for several months without forward progress.

It seems like this isn't reproducible in other environments. Feel free to file a new report if you are able to uncover more information in the future.

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

I am solving this problem. Reason was in empty Callsign in setting repository. After I added callsing, revisions became openable for audits.

i am cloning repo in my local phabricator(ssh only read) and cloning repo in my notebook, then add new file in dir1 "test" and commit he in rSVNTEST then accept commit and i found this revision on my local phabricator where she all the same do not open for review code same all post revisions...

okey im trying pull test repo in my sandbox, but im not sure what it's working. Chad how you can see on offer connect in my local phabricator and see all your self ? :)

We're also not familiar with https://riouxsvn.com/, so maybe removing that host as a variable would help. Phabricator has built in SVN hosting.

Unfortunately no, we need reproduction steps to be able to move further. We need some means of observing the issue in a local sandbox so we can be sure we've found and fixed the right bug. That might mean you isolating the offending commit that is giving Phabricator trouble, breaking down to a minimal test case, and pushing an example to rSVNTEST for us to inspect.

chad you have any ideas what's wrong in my local phabricator or whath next steps i have to do for resove it's problem?

In any case, this is definitely some kind of problem in your local environment and not an issue with the upstream. We can't and won't be able to reproduce it and can't help you with installation and setup issues (see Support Resources).

Oh, wait, you're actually on stable and just haven't updated master.

This column and the property for it were both removed in 32225d1 (Feb 8). You are running b5518d4b (Feb 7), but have somehow upgraded your database using a newer version of Phabricator.

UPD: find error at "arc diff"

thank's, at ulr, I do it

./repository reparse --importing --all --trace  R10

Maybe also related, T10003. Do you have any special configuration for Maniphest?

You can check database status and issues in Config -> Database

Git says "Already up-to-date"
I did restart both nginx and php5-fpm many many times

When we say "restart webserver", we mean Phabricator itself, which means php-fpm for you. See https://secure.phabricator.com/book/phabricator/article/restarting/ for more details.

See also T4854 -- mod_pagespeed is known to be incompatible with Phabricator, and should not be used.

I am using the recent Bitnami Phabricator stack

This problem is probably the same as the one in task T10120. This is probably related to caching since clearing the cache restore the functionnality (at least for some times).
However, in our case, we have a regular httpd server without any mods installed.
Do you have any ideas of how we could debug that ?

Indeed, the case seems to be connected with caching. If the browser cache is cleared and the project manage page is reloaded the policy-rule-editor is indeed found and a custom policy can be edited. However, this occurs only once. When the page is reloaded, or if another project is edited afterwards the issue is back - and can be remedied by emtying the cache, again.

Just shelving this for the moment until more information is unearthed.

Oh, and make sure you restart fully after changing the code -- I suspect that might have been the cause of the revert not fixing things earlier. Here's a guide if you aren't sure how:

Can anyone who is able to reproduce this let me know if this fixes it?

We run origin/stable from rP (times three), except for reverting rP71bda66870d8ef832f4d048b11282f9ae0086f05 to prevent this issue from occuring.

Technically, this is "Invalid" as steps to reproduce the issue outside of the user's environment have not been provided, see Contributing Bug Reports for more information for what we take as a valid bug report. If a reproducible steps are provided and verified, we're happy to re-open and fix any issue in Phabricator or in the Documentation.

It looks like the reporter has moved on for other reasons:

Reporting the same behaviour. Fetch hangs on our biggest repo.
Reverting the gzip commit fixes the problem.

One final idea: Let's just take Phabricator completely out of the equation, assuming you followed our installation guide.

@bob.apthorpe Poor sense of humour on our part aside, what else can we do to help you here? Do you have more specifics on reproducing the bug you can share with us? Unfortunately no one is able to reproduce with the steps you've provided and we have no other reports of issues with installation (T9469 was also a http configuration issue). Your twitter posts seem to indicate this server may not be directly under your control? Can you test in another environment or VM?

The fact that you had to add RewriteCond %{ENV:REDIRECT_STATUS} ^$ implies some redirect loop inside the apache, before phabricator shows up?

I can't reproduce this either: I've created a new dm namespace, with no users, and navigated to / - that sent me to /auth/register/, no redirect loop.

I'm not sure that will work here; I'm running Apache 2.2.

Also "Fishing Expedition"? That's a bit ... insulting. More than a bit, actually.

I'm not sure that will work here; I'm running Apache 2.2. Older, sure, but completely capable of handling redirects correctly. If Apache 2.2 is too old, that needs to be listed as a system dependency up front.

Got the same problem with only one of my repos (~ 50MB, largest one).
Reverting the commit mentioned by @dtf fixed the problem.

(if it helps, this is my virtual host config).

Will do

In cases where we can find the root cause and provide guidance or raise a setup issue, we do. If you do get more information on this, let us know.

I agree, it's fishing. I've done all I can do and gave up. I converted to using SSH instead, which is probably better anyway.

In T10296#157687, @chad wrote:

You're welcome to spin up a test instance on http://phacility.com/ and reproduce there (our platform - your client).

You're welcome to spin up a test instance on http://phacility.com/ and reproduce there (our platform - your client).

Same thing, just one repo out of many (biggest one, only 400 MB, though).
Reverting the {71bda66870d8ef832f4d048b11282f9ae0086f05} helps.

I'm experiencing exactly same problem while accessing one of my repos via HTTP.

We are currently experiencing this problem on one of our repositories, but not the other 50 or so.

I'm out of ideas and can't reproduce this problem, then, so we can't move forward (see Contributing Bug Reports). Here's, e.g., this working fine for me against this server:

I have the same issue with SVN+SSH, but not with GIT+SSH. I used strace. This is the part where it breaks - looks like it breaks after the chdir call (in the middle of the snippet):