3 ms·

My experience with Phabricator is with the code review system (Differential), rules system (Herald), CLI (Arcanist), and API (Conduit). I can't speak to other f

My experience with Phabricator is with the code review system (Differential), rules system (Herald), CLI (Arcanist), and API (Conduit). I can't speak to other functionality like repo hosting or task management. I joined Eventbrite shortly after they moved from Review Board to Phabricator for code review about 4 years ago. It took me a little while to adjust, but once I did I found it to be superior to what Github provided. The CLI provides a nice way to standardize on a workflow company-wide. The UI for composing a review has a few quirks but a lot of functionality, and the patch-based aspect makes it easy to track the evolution of a diff. Herald is very powerful for making sure the right people review a diff. Conduit provided what we need to integrate with Jenkins for CI. Github has gotten better since then, but I'd still lean toward Phabricator as the better tool for code review, especially for larger projects. I eventually partially inherited running Phabricator at Eventbrite, and found it overall to be straightforward to configure and troubleshoot. We were only running a single node and using git for repositories, though. Now I'm at Mozilla, and we recently switched from Review Board to Phabricator for Firefox code review. Some of my teammates run the service, and I know that running a multinode setup with mercurial as the repo format has proven challenging.

deleted 8y ago
[deleted]
dcosson 8y ago
I only tried out Phabricator briefly, and it was pretty good. But the data model bothered me in how it introduces its own abstraction of patches on top of the git branch model. It seems redundant, and also seems like an SVN-inspired model that just felt like a step backwards from having the power of plain git (as in the ability to create diff objects and branch and rearrange them arbitrarily in a pretty simple way, and have multiple people working on these branches at the same time and keeping in sync with each other). I know you can still use plain git locally with Phabricator, but the extra layer of abstraction seemed to only add complexity since now you basically have different data models locally as you do on the server whereas previously they were the same. And what you gain from it didn't seem big enough to justify this, because at the end of the day you can accomplish a lot of the same things in git (like using the squash & merge strategy in github) without introducing any new primitives. I didn't use it long enough to really figure out if this is a purely aesthetic concern and I'm just being stubborn about the way I'm used to or if it leads to real problems in practice. I'm curious what people who really like Phabricator think about this.
- sciurus 8y ago
  "as in the ability to create diff objects and branch and rearrange them arbitrarily in a pretty simple way, and have multiple people working on these branches at the same time and keeping in sync with each other" I can't truly speak for them, but I suspect these are both (reworking the history of code while its in review, and multiple people working on a branch) things that the Phabricator authors would say are bad practices that your tools should discourage. The arguments that come to my mind are 1) Reworking history during review makes it near for your reviewers to understand what is changing. That should be reserved until its time to merge your code, at which point all the revisions along the way should be squashed. 2) Shared development on a branch means the scope of the change is large, and the branch is probably long-lived too. Both of these are arguably bad; I don't have time to argue why, but chapter 13 of Continuous Delivery lays it out well.
  - sciurus 8y ago
    Oops, that was supposed to say "makes it near impossible", but I'm outside the window where I can edit it.
  - Nullabillity 8y ago
    Mercurial's Queues extension had an interesting solution to this. Basically, WIP branches would instead be stored as patch files under version control in a separate per-PR repository. To merge you'd apply each patch as a commit and then archive/delete the queue repository. This would let you organize commits logically, while also letting reviewers query by chronological order. As a PR author it was effectively a `git rebase -i` that you could walk back and forth as you pleased, without destroying any history.
- maktouch 8y ago
  I like the abstraction of patches, because some of our projects still runs SVN and HG, and because we're all on Phab, we're all using the same flow. We actually don't feel any urge to move to git at all (it's probably going to happen some day anyway)
- aseipp 8y ago
arittr 8y ago
Agreed on all points - I think Phab is awesome, easy to use, and most of all easy to manage. I loved it during my time at EB. I think it’s an insanely powerful tool and I have no idea how I could have done my job without the automated herald rules system.
xtracto 8y ago
I used Phabricator for 4 years in a previous company. I used also Differential, Arcanist (for pre-commit code reviews), herald, Maniphest, Paste among others. Personally, I really liked it, except for the fact that the interface feels clunky and outdated. When I was leaving, the company was moving to GitLab mainly to use the "pull request" flow, which is not available in Phabricator.

deleted 8y ago

[deleted]

dcosson 8y ago

I only tried out Phabricator briefly, and it was pretty good. But the data model bothered me in how it introduces its own abstraction of patches on top of the git branch model. It seems redundant, and also seems like an SVN-inspired model that just felt like a step backwards from having the power of plain git (as in the ability to create diff objects and branch and rearrange them arbitrarily in a pretty simple way, and have multiple people working on these branches at the same time and keeping in sync with each other). I know you can still use plain git locally with Phabricator, but the extra layer of abstraction seemed to only add complexity since now you basically have different data models locally as you do on the server whereas previously they were the same. And what you gain from it didn't seem big enough to justify this, because at the end of the day you can accomplish a lot of the same things in git (like using the squash & merge strategy in github) without introducing any new primitives. I didn't use it long enough to really figure out if this is a purely aesthetic concern and I'm just being stubborn about the way I'm used to or if it leads to real problems in practice. I'm curious what people who really like Phabricator think about this.

sciurus 8y ago
"as in the ability to create diff objects and branch and rearrange them arbitrarily in a pretty simple way, and have multiple people working on these branches at the same time and keeping in sync with each other" I can't truly speak for them, but I suspect these are both (reworking the history of code while its in review, and multiple people working on a branch) things that the Phabricator authors would say are bad practices that your tools should discourage. The arguments that come to my mind are 1) Reworking history during review makes it near for your reviewers to understand what is changing. That should be reserved until its time to merge your code, at which point all the revisions along the way should be squashed. 2) Shared development on a branch means the scope of the change is large, and the branch is probably long-lived too. Both of these are arguably bad; I don't have time to argue why, but chapter 13 of Continuous Delivery lays it out well.
- sciurus 8y ago
  Oops, that was supposed to say "makes it near impossible", but I'm outside the window where I can edit it.
- Nullabillity 8y ago
  Mercurial's Queues extension had an interesting solution to this. Basically, WIP branches would instead be stored as patch files under version control in a separate per-PR repository. To merge you'd apply each patch as a commit and then archive/delete the queue repository. This would let you organize commits logically, while also letting reviewers query by chronological order. As a PR author it was effectively a `git rebase -i` that you could walk back and forth as you pleased, without destroying any history.
maktouch 8y ago
I like the abstraction of patches, because some of our projects still runs SVN and HG, and because we're all on Phab, we're all using the same flow. We actually don't feel any urge to move to git at all (it's probably going to happen some day anyway)
aseipp 8y ago

arittr 8y ago

Agreed on all points - I think Phab is awesome, easy to use, and most of all easy to manage. I loved it during my time at EB. I think it’s an insanely powerful tool and I have no idea how I could have done my job without the automated herald rules system.

xtracto 8y ago

I used Phabricator for 4 years in a previous company. I used also Differential, Arcanist (for pre-commit code reviews), herald, Maniphest, Paste among others. Personally, I really liked it, except for the fact that the interface feels clunky and outdated. When I was leaving, the company was moving to GitLab mainly to use the "pull request" flow, which is not available in Phabricator.