@epriestley Yeah, that would certainly be really useful for some cases; I imagine infrastructurally it'd be a good step towards this as well, along with T10569. I don't think it would help this particular usecase though.

Oh, I forgot to mention this but T10333 (groups within columns) is another possible attack here, and one I definitely intend to implement regardless of other work and outcomes (e.g., T5474) since I think it stands on its own and is already well-justified by confusion with priority-ordered boards. T10333#158767 has the ASCII-art mock:

This sounds specific to your local installation. Maybe it's better to implement this yourself locally as a custom field?

Thanks for the report, and for providing detailed reproduction steps.

@Danny_B I am curious about your actual root problem as well. I have heard this from some end users but have yet to get a clear use case. Can you give an example of how you are using your workboards that this is a problem for you. I understand "too much email make it stop" however that is not something that is actionable and very short sighted.

In T4863#152912, @epriestley wrote:

• Diff/Mock: These are fairly straightforward, alhtough I'm not totally convinced that they're valuable. At least in my personal workflow, I don't imagine I'd be likely to ever use them, and I don't recall other requests for them offhand. I'm hesitant about building new hard-coded first-party application stuff, too, since we've made so much progress on getting rid of it. I could build this in a generic way, of course, but that makes it less straightforward.

@epriestley Missed a spot: D16325

This would be very useful for things like blocks of code. If you're suggesting a few options for a certain bit of code, or using a list to explain changes to multiple interfaces (code is much more concise than prose), nested code blocks would be very useful.

In T4770#187220, @chad wrote:

@nealsun https://secure.phabricator.com/book/phabricator/article/diffusion_autoclose/

@nealsun https://secure.phabricator.com/book/phabricator/article/diffusion_autoclose/

so how to set the configuration to auto close revision after arc land?

At this time if you want to use Phabricator with Windows development, you pretty much have to be prepared to have some support resources and patches internally because Windows isn't a platform that the upstream frequently uses.

running arc patch locally to test the patches should take you less than a minute.

@eadler We are all appreciate your work. I understand you have your own reasons why not applying those patches. But I also know that we cannot use

svn mv

Which is critical operation for development.
On the other side I don't want to miss a history for a file so I cannot use

svn rm
svn add

For now we don't have a hook on our svn (because it still POC) so we commit and then Audit but it really frustrate our team (5 people).

In T11367#187161, @epriestley wrote:

Phlux should probably be on the chopping block too since Almanac pretty much obsoleted it in Phacility production.

I'm hesitant to axe it because Sitevars were so useful at Facebook as a flexible, general-purpose tool, but I don't currently have any use cases in mind for it that I'm particularly excited about.

Phlux should probably be on the chopping block too since Almanac pretty much obsoleted it in Phacility production.

@eadler - oops, sorry about that then :) I'm still behind what I said though ;)

In T8298#187157, @BYK wrote:

@eadler - I'd like to remind you that there are 3 patches waiting for review right now. They have been ...

I don't work for phacility. I, like you, occasionally contribute code as well as administer at this point 5 different copies of phabricator. Sorry for curt tone above.

I'm not sure if Phacility wants it to be used this way but it may be possible to setup a Fund Initiative for prioritizing this. I would likely be able to secure some funds for this feature.

@eadler - I'd like to remind you that there are 3 patches waiting for review right now. They have been sitting there for a few months. That said we are not paying Phabricator. If the only way to get these patches which are already worked on and in pretty good shape merged in is to pay you or maintain a fork I'm really starting to think about crowdsourcing this on Kickstarter or Indiegogo to collect those few hundred bucks to get already working patches landed or simply create a fork and point people there loudly. I also think I almost qualify for "Rise to prominence" sub-section mentioned in https://secure.phabricator.com/book/phabcontrib/article/contributing_code/#alternatives but of course that also relies on you guys letting me contribute more. Making patches sit for months without any feedback and then making me rebase them multiple times is definitely not a great way to encourage people to "Rise to prominence" if you really value that.

currently phabricator is POC on our team, if the company would like it they would purchase it. currently we don't have any budget for POCs at all.
The only thing I can do right now is look into the code and fix it (contribute code).

In T11367#187111, @hach-que wrote:

Users don't have anything to do with Phragment? Unless I'm misunderstanding something?

In T8298#187116, @davidhodeffi wrote:

can you please raise the severity for this issue ? It is really hard to work like that
when renaming a file 'svn mv'. for now we are just committing the code and using an Audit.

can you please raise the severity for this issue ? It is really hard to work like that
when renaming a file 'svn mv'. for now we are just committing the code and using an Audit.

@epriestley I was trying to recreate my problem I had a month ago and write a task (bug report) for it and wasn't able to reproduce the issue of Drydock trying to allocate resources indefinitely. Have you already added a timeout to Drydock leases?

Users don't have anything to do with Phragment? Unless I'm misunderstanding something?

Any estimation how long can this be fixed? If it takes long, I will break the parent/subproject relationship. Otherwise I can just wait for the fix.

In T11367#187106, @hach-que wrote:

Phragment is super out of date and FYI, hasn't seen any usage from me for a while. I don't know if anyone else is using it, but you can probably feel free to just delete the whole thing since it's a prototype anyway.

Phragment is super out of date and FYI, hasn't seen any usage from me for a while. I don't know if anyone else is using it, but you can probably feel free to just delete the whole thing since it's a prototype anyway.

@epriestley When merging task which is clearly speaking about something else (although related), please update the task title and description to contain the data from merged task so they won't get lost. Thank you.