I'm having difficulty reproducing this. Here's what I did:

What are the view, edit and join policies of the parent project set to?

Ah, interesting. I have F1 bound to "Expose: All Windows" so the flow for me is "Click > F1 > Drop Anywhere" to save, then "F1 > Drag > F1 > Drop" to load. I'm pretty sure I can get through that faster than I could copy-paste/type-select a file by Fxxx or from a browser UI.

Note that being an administrator doesn't matter: administrators have no special privileges, and can not bypass policies. See:

Thanks, your reproduction instructions are clear and complete. I was able to reproduce this by following your instructions and narrow it down to a root cause. This should be fixed shortly.

I'm having trouble reproducing this. I tried to follow the instructions you provided to recreate the issue, but didn't seem to experience it. Here's what I did.

Hi! Can you please let us know what version of Phabricator you're running?

In conclusion, we should never add options to the product.

(The difference between the dark and default background colors is so subtle on my monitor that I never noticed it.)

Oh, I do have that set locally -- I thought phui-theme-dark was just the default (since we got rid of light?) but this fixes itself if I switch to, e.g., the red header.

When creating the first subproject there is a note that all members of the project will be moved to the subproject. In fact, members were copied to the subproject

T10349 has a similar use case, where a user would like to select an existing file for use as a cover image.

Thanks, that's helpful.

This gets a brief mention in the documentation, but generally:

Hi! Can you tell me what version of Phabricator you're running?

In the very, very general case, I think it's undesirable to favor "N" over "U" because the reports could be coming from two different engines, only one of which knows how to execute the lines.

I added you to Community if you want to do the honors. :)

I can't immediately reproduce this, here's what I get:

Since only the first connection has an issue, you could also conceivably add a slightly-more-than-one-line patch to make arc land run some no-op remote operation (git remote show origin?) and then immediately kill the subprocess, creating and throwing away the bad connection so the followup doesn't hang.

If you're open to patching one site, you can just comment out the feof($stderr) to retain the bulk of the change (i.e., still wait for stdout).

I can sort of see arguments either way, although I think I'm inclined to names too.

Change milestoneNumber in phabricator_project.project to reorder milestones.

Is sorting by Space ID (instead of Space name) definitely your preferred sort?

This is unintentional, I only meant to hide archived projects on workboards. They're incorrectly behind hidden in all contexts.

Sorry, I'm still not sure I quite understand the specific use cases for this feature that you anticipate.

The benefit of enabling ControlPersist is only very slightly faster SSH connections, right?

Do you legitimately have several distinct "profiles"? What differs between them?

@20after4 It would be helpful to get a sense of what your ideal tree looks like -- would adding the immediate parent project always be sufficient to disambiguate things? Or would it produce 30 different projects named iPhone > Bugs because the full hierarchy is CrazyFlaps > iPhone > Bugs, FlappyFish > iPhone > Bugs, etc? Or do you have a mixture of hierarchy depths?

If the parent is already a parent project of some other project, it has no direct members, so nothing will be copied. --keep-members parent should do what you want, provided you move "Members" first, before "Subproject A" or "Subproject B".

@nochum, can you explain what you're trying to do in more detail?

Quick summary here:

I also think the current per-service and per-device granular locking might be better off as a cluster.locked global configuration which prevents creating or editing anything touching a cluster service, so I may pursue that.

This just sounds a lot like "I ran rm -rf /var/repo/X/ and all the data for rX vanished" to me, which is completely expected and should be predictable.

None of the repository replication code is even written, though. What behavior do you expect today?

Suppose you have a hosted, active repository and do this:

Does changing window to 31 actually fix it for you?

Workboards only. See T4213 for discussion of themes and skinning.

Thanks for verifying the fix!

In the Phacility case, I can also just give these networks a "no one" edit policy, but still need to do the namespace locking.

From IRC, I think it sounded like this wasn't really a bug so much as a confusing UI (expecting to type one thing when the UI wants something different), exacerbated by the lack of "Browse" working. I'm just going to realign this to be "make browse work".

I think this is now resolved for PHP 5.6 at HEAD of master.