This is caused by this change: https://secure.phabricator.com/D7468?vs=16834&id=16838&whitespace=ignore-all#toc, which ironically is the difference between the accepted revision and the code that was landed.

We could just prevent deletions from syncing; it would mean that S3 never gets garbage collected, but it's reasonably low-cost and if someone wanted to garbage collect the S3 bucket they could just delete it and let Phabricator resync the whole thing.

Is there any reason that both features can't be implemented? One mechanism that uses git push to mirror it to other Git repositories and uploading each Git object in the .git directory to S3 as they are added / changed. I know if there was a mechanism to store a copy of the Git repository in S3 that's make some people a lot more comfortable than "it's sitting on a web box" (which is the case at the moment).

The use case is more of a theoretical one. Basically at the moment the (small) amount of internal documentation we store in Google Docs. It seemed like a good idea that we should be able to store this information in Phriction but use policies to restrict who can access it.

Ideally we might want to plug this into Fact instead of yet another reporting system. Otherwise we're just going to end up with the next architecture problem like transactions, search and custom fields before it.

D7165 is an example of how this could be achieved (although lacking in a lot of infrastructure / landability).

The dialog and link is quite heavy; it implies there's something to actually change with the dialog (similar to the way you can edit what objects relate to a task in the action list, these also popup in the same kind of dialog).

One of the latest changes to make the policy information on an object clickable (e.g. you can click "All Users") sort of implies that you can change it by clicking it. It might be a good idea in the future to allow changing the policy from the dialog as well (for those that can actually change it).

(2) sounds good to me. I don't like the idea of (1) because it would permit any form of Remarkup, and in this case we explicitly want to store a link in that field.