I've been using the code review portions recently. The pre-commit workflow doesn't work too well with git, since the review happens before you upload the code. So everyone needs a local php program to both upload code diffs, and download the code diffs (to support multiple VCS systems). And once it's approved, you need to merge and push it locally (there is a command in the program to do this in one step).
Writing unit tests also requires making (a small) php program to call out to them. And from what I've seen, it only supports them locally, and not through another system. There is a post-commit review system, but it has less features, and is based only on commits.
But after looking around, there really wasn't much else that fulfilled the project-management aspects as well as code-review.
I've been using Phabricator for almost a year now in our company. At first, I also had my questions about the workflow with arcanist (the local PHP cli software to interact with Phabricator). However, right now I really love it and miss it on every repository which works without Phabricator. Commands like 'arc feature', 'arc tasks' and 'arc inlines' provide a solid abstraction over the repository to bring the workflow to the cli.
About the unit tests: indeed, out-of-the-box Phabricator only supports running them locally (you can configure the unit engine to run every time a piece of code is been send into review). Luckily, it's not that hard to hook into the event engine (https://secure.phabricator.com/book/phabricator/article/even...) to, for example, trigger your CI-server to run the test suite for a specific revision.
Also, Phabricator is still being developed actively. There are a bunch of alpha and beta applications which will only make it more powerful (for example: DryDock and Harbormaster, which will ease the work for automatic builds: http://www.guywarner.com/2014/05/integrating-jenkins-and-pha...)
In my opinion, Phabricator is one of the most powerful tools around for doing code reviews and effective collaboration management. Even with the large amount of beta applications (which are promising in many cases) the decision for us was easy to make.
Since it has been broken some time ago: no. But when it was still working: yes, I found it rather useful. Especially with very small commits/bugfixes and such.
I hope they'll fix it soon
Yes, the pre-commit workflow is also why I won't use it. I want to review branches, not patches. With branches though, there's another problem which AFAIK no code review tool can manage, with the sole exception of Gerrit: force pushes. While you might recoil, I think force pushes are often an entirely reasonable thing to do on a feature branch which is not yet merged into mainline, especially when cosmetic stuff gets fixed, like trailing whitespace, hanging braces or whatever the reviewer did not like. You really don't need that kind of history in mainline. See also this comment w.r.t. to GitHub's inability to deal with force pushes, to which I entirely agree:
Why do you want to review branches? Doesn't that encourage longer divergence, therefore decreasing the percentage of atomic commits and increasing the risk of every merge?
The issues you name are certainly valid, and I would only recommend this with a VCS that offers a wide range of possibilities for rewriting history. In the ideal case, a feature branch is a unit which implements a feature, fixes a bug, etc., and is usually comprised of several commits to achieve that. The advantage is that you clearly see the steps needed for achieving the desired result, each with its own commit log, and arranged in a logical order. Of course, you can do this with a set of patches as well, but then you need tooling separate from your VCS to manage that. Git has excellent support for re-arranging your commits, splitting/combining them, rebasing them onto current HEAD or onto some version branch.
Shopping around for these kinds of tools recently. Phabricator looks great, but the point you mentioned is a show stopper for me. I would love to see Phabricator have GH-style code review, even if it meant dropping support for non-DVCS. Arcanist is neat but I don't want to learn a proprietary CLI tool just to do code review.
Atlassian is expensive and only supports GIT, but the UI for VCS is way better (as is the Jenkins integration).
It isn't proprietary, it is open source php. Not wonderful, but the cli works well and hits all of the phabricator bits you need. I've been using it for ~6 months and like it quite a bit.
Maybe proprietary isn't the right word. I don't like that the only way to do pre-commit code review is using a CLI tool that only works with Phabricator. Contrast this with the GH-style system where you use a standard Git client and a web app. The GH-style system is just much more accessible.
While GitHub isn't that great, it's sufficiently popular that there's a bunch of tools built on top of its API that supplement its failings. For example, for code reviews you can hook up https://reviewable.io (disclosure: my project), which automatically inserts links to itself into PR descriptions and doesn't require using any new CLI tools.
If you want a nice interface, you should take a look at GitLab. It only supports Git, but it is free software and its user interface is the only one that, in my opinion, can compete with GitHub’s (it is more or less a free software clone of it).
I'm a little confused by what you mean by "the review happens before you upload the code"? Can you explain what you thought should happen vs. what does happen?
Phabricator rocks, primarily as a code review tool – we've been using it at Khan Academy since 2012. It's sad how much better it is than GitHub PRs, especially for a large team. I'm looking forward to watching it continue to grow. :)
Could you elaborate on its benefits vs. GitHub? Having used Phabricator in production for over a year and a half, I have been consistently disappointed by its horrendous user experience, lack of integrations, and overall difficulty of use.
Compared to GitHub, it has really been night and day.
GitHub doesn't have a way to assign reviews to more than one person or to see the code reviews that you need to take action on (meaning code you need to review or reviews you authored that need updating, without showing reviews that you're waiting for another person on) on a single repo, let alone across all repos. GitHub's emails are incredibly noisy to the point that I'm reluctant to make inline comments for fear of spamming people's inboxes. When someone updates a PR, it's hard to see what's changed since the last version you saw.
Phabricator also has other niceties like syntax highlighting within diffs, two-column diffs (which admittedly GitHub added about a month ago), and a solid command-line tool ("arc") for sending off reviews, etc.
A bit of hopefully useful self-promotion: for those interested in all* of these benefits without ditching GitHub, check out https://reviewable.io. It has batch comment support (as well as one-off instant send), incremental diffs between revisions (even when rebasing), syntax highlighting in diffs, responsive one- and two-column diffs, and more. And there's no new command-line tools to install and learn -- it hooks right into GitHub.
* The review dashboard already shows all the reviews you're involved, but not yet which ones require action. This feature is coming soon -- I have all the data, just need to add some code to massage and display it appropriately.
Even in Phabricator, though, when you have multiple reviewers only one has to accept for it to be accepted. Oftentimes it is _more_ confusing to have multiple reviewers because you don't know who should have the final say.
The commenting system is a matter of preference, but having forgotten to "Clowncopterize" (a great demonstration of the professionalism of those who hack on Phabricator) comments, and given that they thread in email, it hasn't been a problem for me. Though I understand where you're coming from.
> Even in Phabricator, though, when you have multiple reviewers only one has to accept for it to be accepted. Oftentimes it is _more_ confusing to have multiple reviewers because you don't know who should have the final say.
Yeah, this depends on workflow. We generally send every piece of code to two reviewers but just wait for either one to accept, unless there's a particular reason that both should look at the review. This works well for us but I can see how it wouldn't work as well for people with other processes.
> The commenting system is a matter of preference, but having forgotten to "Clowncopterize" (a great demonstration of the professionalism of those who hack on Phabricator) comments, and given that they thread in email, it hasn't been a problem for me. Though I understand where you're coming from.
Yes, Phabricator's isn't perfect but it's the best of the ones I've tried, especially if everyone using it is familiar with the tool and uses it frequently (that is, you might forget to Clowncopterize once or twice ever, but then you'll know for the future). I used to use Kiln (http://www.fogcreek.com/kiln/) which had a different approach for emails – they essentially debounce emails to have a half-hour delay and coalesce any emails within that timeframe together, so you get fewer emails but don't need to submit the collection of comments explicitly. Having tried all three choices, I'd say that they're all painful in different ways and I personally prefer Phabricator's approach.
> Yeah, this depends on workflow. We generally send every piece of code to two reviewers but just wait for either one to accept, unless there's a particular reason that both should look at the review. This works well for us but I can see how it wouldn't work as well for people with other processes.
For this Gerrit[1] does offer the possibility to fully customize the approval process. It's a bit freaking odd at start because it relies on Prolog [2] but it's the way to tailor the tool to your process
> Even in Phabricator, though, when you have multiple reviewers only one has to accept for it to be accepted. Oftentimes it is _more_ confusing to have multiple reviewers because you don't know who should have the final say.
Phabricator allows "blocking reviewers", meaning that those reviewers must. There can be any number of blocking reviewers. These reviewers can be groups or individuals. For example, you could require someone from the "Security" group to accept every revision.
I have no idea where that help page took those screen shots from... but it is definitely not from github.com or github enterprise. I see no way to assign pull requests... i don't even see the checkbox they mention on the PR list!
You need to have someone to assign the PR to. Either you need a second contributor on the repo, or you need to be in an organisation with more than one member.
I prefer github, personally. Mostly because it doesn't fight the nature of git as much (though, surprisingly, it sort of does a bit).
Particularly, if you have a back-and-forth of changes on a PR, the inline comments that relate to lines that haven't changed stick around (and references to no longer connected comments are available in the UI). I find this huge for progressively dealing with things. And it does this whether you've force pushed a rebased cleanup or just capped another change onto the PR's branch.
And then there's the way phabricator manipulates your commit messages in rather elaborate ways that are often confusing or frustrating. It also shows that the authors don't have a lot of respect for the idea of using merge bubbles over squashing commits, and I much prefer bubbles. And because of using merge bubbles primarily, github can tell when you merge a PR even if you don't use its tools to do it.
And while I like the ability to batch comments, I don't like that it makes you always batch them. Sometimes I really only have one thing to say and it's way too easy to forget to submit.
Likewise I like the ability to do pre-review tests, but for a large codebase I also really love the commit-hook UI cycle of github's integrations with stuff like travis and circleci, because a lot of the things I've worked on in the last couple of years have full compile+test cycles in the 10s of minute ranges.
Two column layout, the batch commenting, pre-review-tests, and the code highlighting are all great. But I really prefer tools that really strongly integrate with git. I'm not really interested in vcs portability at this point.
I often wonder how many people who have really strongly negative opinions of GH PR workflows have been forced to use it with full forks instead of a shared repository. Honestly, github forks are terrible for anything but casual submission of open source patches (and even there I think there'd be better ways). I've seen people try to use them for more serious stuff and it never goes well.
FWIW, I found a better (it isn't the default) workflow with phabricator. If you set:
"immutable_history": true
In your repo's .arcconfig, it will work this way:
When creating a topic branch and you "arc land", it will only put that nasty phabricator formatted commit message in the merge commit that merged the topic branch into the master/develop branch. When you just submit a review against the branch you want to land to, you simply git push, and the review message doesn't go to the repo.
This gives us the best of both in that phabricator doesn't overwrite our commit messages, or rebase squash things, but we get the phabricator metadata in the repo when we want it.
I had actually forgotten about that from the last time I used phabricator, thanks. Alas, this time a lot of my frustration is born of the fact that I'm actually working on something where the upstream is an svn repo, where I'm using git-svn with it. It's kind of a perfect storm of not very good tool interop, but I've made it work somehow.
Dropbox uses Phabricator extensively for all our projects. Integrations into CI and deployment systems, etc. Great project.
I've used trac, redmine, bugzilla, github/github enterprise, over the last ~10 years, and taken across the whole feature set, Phabricator outshines all of them. All the integrations across the product suite are nice, and the arc tool is really convenient once you get used to its quirks.
It's not the simplest thing in the world, but if you have a bigger shop with some nontrivial workflows, lots of projects, lots of teams, blocking reviews, mandatory security reviews, etc... Phabricator is a great way to wrangle it.
Every time I saw a project management tool I instantly want to compare it to redmine which is based on Ruby. I failed to see obvious advantages from Phabricator yet.
Seriously, Redmine is your standard? It has to be one of the clunkiest, slowest and all around uncomfortable project management tools out there. We use it at our place of work, and out of 30+ developers, only a handful of people are content with it.
If you are looking for something that does "more than just git" and if being open source is valuable to you, you can have a look at Tuleap[1].
It comes with git and svn for source control, built-in tracking technology (big difference with redmine/jira, anyone can customize models & workflows), code review with gerrit, agile dashboard for scrum (kanban on going). Last but not least, it does scale quite well (10k users, 200k tickets, TB of git repo, ...)
Looks nice! A hint though: I was looking for an open source tool and I didn't stumble across yours, so you might want to put some effort in SEO, presence on blogs,...
I find the information on your download page (https://www.tuleap.org/try-and-go) a bit confusing. What do you charge for? I need to know that up-front before investing my time... There are many products which are "free" until you need some (basic) functionality.
Also, you might want to check spelling on that (and probably other) page(s), but I don't personally mind that. :)
Thanks for the feedback, indeed we are not very know yet but we try to improve (I've heard this place is good at it :D).
Tuleap is 100% libre and open source, you don't have to pay anything to use it. All the things you see on tuleap.org are immediatly available and usable without "freemium" or "open core" principle.
Thanks for the answer - I misunderstood completely. This is the text that confused me:
> There is no differences between an “evaluation” and an “enterprise” version. We want you to experience the full power of the Tuleap software. Just follow the instructions to install your instance.
The way I understood it there are two versions, "enterprise" and "evaluation", and there is no difference between them (well, except for probably price, support and maybe some other hidden goodies). So next thing I tried to find info on this "enterprise" version, and could find none. :)
I would suggest you word it a bit differently... Your answer is much better at conveying the business model than the current page.
I am more or less in the market (and evaluating) such tool suite and I must admit that I am pretty impressed at what you have here. However if I can find one downside of the UI is the lack of sheen; things that other tools out there (that get often 'promoted' on HN have).
I've been Jira user / Jira consultant for some time (around 3.x - 4.x versions). And I loved the tool then. I don't have the same sentiment any more and mostly find it bloated.
At the moment I'm daily Redmine and YouTrack[1] user and find both of them much more superior.
Personally I think YT is one of the most user friendly tools out there, but I also find it quite limited and lacking (especially in regards to reporting and time management). However it seems it's being addressed with 6.x version (it's still not at the point I would like it to be, but hopefully the trend will continue).
At the moment I don't see any viable and full-featured alternatives to Redmine frankly, which is disappointing. I like the tool, however it could be more user friendly (modern) and easier to maintain (at least for non Ruby guy). I'm considering to give a OpenProject[2] a trial demo someday, maybe things are better there (basically it's another Redmine fork).
Regarding Redmine performance - yes it could be better. However it my experience it does scale quite decently (e.g. Jira used to have major problems with it, please bear in mind my experience with the tool is ~3 years old, hopefully it's somewhere addressed currently). In one of our Redmine setups we have around 41k issues and we do not experience any major problems with it.
It has code review that doesn't suck. Redmine is wonderful for issues, but it has no sane code review bits. Also, the gitolite plugin is horrible (I've had to hack several bits of it to work), and there is no really good way to do fine grained access control for your repos.
This is all out of the box stuff you get with phabricator. It does those bits exceptionally well. The niceties you get with redmine, such as referencing commits or issues and autoclosing them on code push also exists with phabricator.
Think of phabricator as a more meme friendly superset of redmine.
It took a while to set up but Redmine Git Hosting Plugin worked well for me on gitolite-based repos. The web git-diff from Redmine's git kind of helps code-review but it's indeed not ideal. I wish redmine is written in PHP so I don't need run Ruby, as all my other server software are in PHP. otherwise, Redmine rules.
We don't actually use phabricator for code review yet :) It just replaced RT and bugzilla (and hopefully mingle). Gerrit migration happening over the next few months, pending community consultation.
I started playing around with phabricator a few months ago. It was by far the easiest web application install I've ever done, and works really well.
The only downside is that it doesn't allow you to do code review via git pull request. It originally was just SVN, but now has git and hg support, and it uses the same code-review tool for all of them, so it's a bit less git-centric than github.
That being said, they have a command line tool for submitting pre-push code reviews that is really really nice. I haven't figured out a way to easily do a github pull-request from the command line (though I'm sure there's a tool to do ti somewhere).
Interestingly, the FreeBSD project also started using Phabricator as a code review tool, under reviews.freebsd.org. As of now its only used by committers and developers, but there is work being done to open it for the wide audience.
It's a shame FreeBSD can't move more things to Phabricator. The bigger the project the better having all the pieces in one tool makes things. Relating code changes to issues and tasks being the most obvious.
I introduced Phabricator to my company about 9 months ago. The trick with Phabricator is that each individual applet/tool is a little bit janky. Taken individually, there are better ticket management tools, better wikis, better code review tools, etc.
But Phabricator's power is in the whole being greater than the sum of the parts. As a unified ecosystem we've found huge power in our code reviews living next to our wiki living next to our user stories living next to our wireframes (pholio).
And yes -- even the business, operations, and account management departments are using it now too!
This is why it's my new standard for this kind of tool. Having a single unified system for all this stuff is so much better than the patchwork of things I used to have to maintain.
Evaluated this when it was still a Facebook project. Decided not to use it as too hacky what with the arc stuff, what looked like weird technical-debt-laden feature creep, and a PITA install. Glad to hear they've fixed the install and they're cleaning it up. Might take another look.
Why does Phabricator's own site (phabricator.org) link to their own source on GitHub? If Phabricator is great for code hosting, shouldn't they be hosting their own code with it?
Phabricator isn't code hosting, it's repository viewing. The code is still hosted in whatever existing SCM tool is being used.
It does have a lot of features that overlap with github which is why it is a bit confusing.
Generally speaking, we proxy requests and pass them through to the VCS after performing authentication and broad permission checks. Requests are rewritten slightly to remap user-facing display paths to actual paths on disk. Some additional features act through commit hooks.
