So I've determined it is a conflict between my .htaccess rewrite rules and some other apache/server configuration. I'm not exactly sure what's happening, but here is an update on the behavior.

T10301 and T9469 are related issues, but neither had any resolution. Would love to know what causes this on the Apache side, if we can improve documentation, etc.

You can also just replace index.php in webroot with <?php var_dump($_REQUEST); ?> to rule out any hanky-panky from Phabricator.

Maybe give it a spin in Charles? https://www.charlesproxy.com/

That's how I originally had it configured, but now I'm using OS X Server. When installed it stops using the default /etc/apache2 configuration and instead uses /Library/Server/Web/Config/. I have a few other websites configured on my home vpn which are accessible via site1.mydomain.ddns.net and site2.mydomain.ddns.net. I have the phabricator alias record configured the same way.

I run dev on a local OS X machine, basically I just manually set a DNS inside with /etc/hosts in my house (dev.macbook.local) on each machine I want to access it on. I'm curious if its a ddns issue.

I'm still not sure, but I cannot verify like I thought before it was related to the rewrite rules. My setup is on a device running OS X Server. I have the phabricator installation at phabricator.mydomain.ddns.net, but I am still continuing to see the "Request exceeded the limit of 10 internal redirects due to probable configuration error."

In T10352#159245, @ianvkoeppe wrote:

This task can be closed.

This task can be closed.

Thanks, looks like we updated the links a month ago but missed rolling the server.

@mrkanaly I had a similar issue. Putting the following in my .vimrc allows me to type arcl to get the same behavior as the old arc land command:

I had to rename all those junk records just so I could hide them after the fact.

Wow. This is awesome. I'm glad you were able to find and trace down this issue with what minimal info I could provide. I'll try to give better descriptions in the future. It would also be nice to remove columns that have no tickets associated with them.

At HEAD:

Yeah, that's the right way; result is a required parameter for unit object.

In T10346#159072, @robertkraig wrote:

they never existed before when I originally imported their workboards

These are sub projects imported from another project. But they never existed before when I originally imported their workboards. So I was as confused as you to how they suddenly started showing up.

Currently, it's hard from me to tell what's going on in the screenshot. Can you give us any more details on the setup?

This mostly applies to if you're following master. stable is only updated once a week.

We expect people to update Phabricator before filing a bug report. We fix bugs very quickly. Even if you just updated a few hours ago, it's helpful for us to not have to spend time hunting down a bug that was already fixed.

I just updated code early in the day, like 2am.

Specifically, what version of Phabricator are you on? There has been a lot of churn on Workboards this week, and even today. Does this bug exist at HEAD?

how did they get added in the 1st place?

Thank you Evan. I found the reason of the issue.
I'm using your batch file to upgrade and when I run it shows the error below.

If you updated two hours ago, you should be ahead of c2502f1, which is about 50 hours old. We've made about 30 changes between c2502f1 and HEAD, which you can see here:

I updated 2 hours ago. And I have just updated.
The issue is still the same.

Update to HEAD. This was fixed by D15232.

2 days is a very long time to import. I'd wait until it's finished (we should still fix the error if we can reproduce it)

Is the import complete?

In T10341#158952, @chad wrote:

Is this Subversion?

It must inconsistent:

• doc said "at least 8mb to support large file"
• truth is "bigger then 4mb will work"

For now, I'm just going to do this:

I think this should all work properly and consistently now, let me know if anyone finds a way to break it.

I believe this is now fixed at HEAD of master. It should promote to stable tomorrow morning.

Is this Subversion?

Unfortunately we can't fix bugs we can't see (well, usually). If you have further details (like what type of repository) or errors in your Apache log, please post them.

Hi @chad , I added some info. I don't know the real reason honestly.

Please see Contributing Bug Reports. Specifically we can't take a bug report without you providing the reproduction steps. How can we reproduce this error?

I have solved the problem. A unit test was outputting a status that was not understood by my XojoUnitTestEngine class. It therefore was not setting the Result of a single unit test. I changed my XojoUnitTestEngine to read:

Awesome, thanks for testing! I think this should be an easy fix, now.

I think that may be important:

To prevent confusion with Git/Hg/Svn tags: What about "Label"?

Confirm. After deleting of mentioned line on top of stable everything clones fine.

I just tested it and it seems like removing the line solves the problem.

In T10326#158479, @chad wrote:

I think I suggested "Project Tags" at one point.

I think I suggested "Project Tags" at one point.

I think it's probably better, but renaming it causes this in Diffusion:

Understood, I just don't know if it was intentionally not converted (@epriestley made the changes). It's just one line in the code and it'll update on all the Property Lists. Do you feel Tags is better everywhere over Projects. That is, are your users less confused about the product?

I see. It's also still "Projects" in Maniphest - I assumed the intention was to rename it everywhere where "projects" carries similarities to "tags" in a broad sense, since a common misconception about our users is for example that repositories or tasks "belong" to one project alone. I already explained that this is not the case to most of them several times and also wrote it in our internal documentation, but it still comes up, especially for people new to Phabricator. Thus I assumed that this is also a common misunderstanding in other groups and the renaming effort is targetted at this exact problem.

But maybe @epriestley did want this field changed also?

I think "Tags" in the Property List context is incorrect, since other data about the Project (like the Workboard its on) is also provided.

In T10323#158405, @chad wrote:

You sure this isn't a dupe?

Your proposal seems even better than mine as it does not depend on the manifest ordering. I will be happy to see the fix showing up in the repository.

This is a super minor issue and not blocking anyone, so I'm changing it to Wishlist priority to designate how much I don't expect upstream to spend time fixing it.

what did Chrome even do here