We are trying to move all HHVM development from Facebook's internal phabricator instance to our public http://reviews.facebook.net/ . HHVM lives in a subdirectory inside of a larger git directory (fbcode, if you remember). We would like to put a .arcconfig in the hphp subdirectory and then have diffs applied to that directory go to the open source phabricator. If a diff spans any files outside, then I think it is totally reasonable to throw an exception and not let them upload that diff.
Description
Description
Event Timeline
Comment Actions
We've been trying to simplify .arcconfig and remove Facebook-only code in the upstream, and this generally moves things in the opposite direction, so I'm pretty hesitant about it. Generally, it's hard for us to prioritize work for Facebook against work for the many users/installs that are more actively engaged in Phabricator direction and development. See also T1206, T3982.
A questionable workaround might be to combine arc alias with the --conduit-uri flag, e.g.:
arc alias xdiff -- diff --conduit-uri=https://reviews.facebook.net/
Then you could run arc xdiff instead of arc diff.
You could also hypothetically check out two copies of fbcode/, and use arc set-config --local phabricator.uri https://reviews.facebook.net/ to point the HHVM copy at reviews.facebook.net.
Comment Actions
@epriestley I'm totally with you, we don't want any special casing for Facebook. I was just hoping others could benefit from this as well.
- For your arc alias hack. That is local and each engineer on the team has to do that once, right? But it would be global to themselves so in any random repo they could send it to the open phabricator?
- For the set-config hack, that's setting a setting to the repo only for that user, right?
- For both of those, it is an extra step that I'd have to ensure each member does. Is there a way to make a "arc diff hook" or something so that the internal facebook repo won't allow the creation of diffs for this subtree?
Comment Actions
I think every request we've ever received in this vein has been to improve support for a large number of small repositories (vs a small number of large repositories) and reduce/simplify .arcconfig and configuration, which is why I suspect only Facebook would ever use this.
To your questions:
- arc alias is per-user, yes, and global to that user (stored in ~/.arcrc).
- arc set-config --local is per working copy, and stored in fbcode/.git/arc/config or similar (depending on VCS).
For (3), not really. Best I can come up with offhand is that you could create a project named "YOU DIFFED THIS TO THE WRONG PLACE YOU SILLY GOOSE", then install a Herald rule which adds a that project as a reviewer based on repository/paths. I think Facebook is still some distance behind project reviewers, but I'm not sure. This is pretty weak as a workaround, though.
You could also write a linter or unit test step which examined the Phabricator URI and failed/errored if it wasn't correct.