On Fri, 10 Aug 2012 00:52:33 -0700, Marcin Cieslak saper@saper.info wrote:
Daniel Friesen lists@nadir-seen-fire.com wrote:
Why is arc written in PHP? That seems to be a horrible software decision to me. Core extensions not enabled by default can be hard to install on some OS. And imho the packaging setup is not as good. Frankly I gave up trying to get mcrypt installed on either version of php installed on my Mac.
It could be improved to check for curl and bcmath (the ones I found out are needed) on startup, not during some other command after other succeded (unless of course the extension is needed only for some specific operation not applicable to general public).
This one I find interesting:
arc looks as if it works completely with patches on it's own rather than doing anything with git.
I can't see how phabricator can have commit workflow support any better than gerrit when it appears to take the repo completely out of the question.
Erik also wrote this earlier:
As I understood it, the big gotchas for Phabricator adoption are that Phabricator doesn't manage repositories - it knows how to poll a Git repo, but it doesn't have per-repo access controls or even more than a shallow awareness of what a repository is; it literally shells out to git to perform its operations, e.g. poll for changes - and would still need some work to efficiently deal with hundreds of repositories, long-lived remote branches, and some of the other fun characteristics of Wikimedia's repos. Full repo management is on the roadmap, without an exact date, and Evan is very open to making tweaks and changes as needed, especially if it serves a potential flagship user like Wikimedia.
After Gerrit, I think it might actually be a GoodThing(tm) to detach the code review tool from managing the repository.
Git at its core is a tool to quickly snapshot directories. Blobs are its first-class objects, not patches or diffs (this is I think pretty innovative looking at the traditional version control systems).
I think there is a reason why Linus settled with email patch workflow that is even included in the git user interface.
Keeping patches and commits separately starts making sense to me - otherwise one ends up in rebase hell.
//Saper
Managing repositories and rebasing have absolutely nothing to do with each other. In fact the managing being discussed is talking about access controls and perhaps creating repos, etc...
Git's storage of blobs rather than diffs is also irrelevant. There is nothing wrong with review being a tree of blobs noted as based off of the sha1 of a previous tree of blobs. Heck this is something that would make an overview diff of multiple commits inside of a review branch really sane.
And Linus settled with an email patch workflow so he wouldn't have to write a new review system in addition to a whole vcs. It has nothing to do with whether changes for review in a review system a better as deltas or blobs. Linus is working with a hierarchical pull-request model with multiple lieutenant maintainers. Something we explicitly chose not to do. So his choices in that area have no bearing on what is the best way to do a review system.
Rebasing has absolutely nothing to do with whether changes for review and actual commits are stored in the repo or separated from it. In fact, quite frankly, working with diffs instead of commits and then applying the diff to the latest version on commit is almost exactly the same as rebasing.
Rebase hell is a screwed up workflow which is 100% by gerrit design. There was nothing about the model they chose to write a review system that forced them to use a rebase+patchset model. Rebases were their choice when they could have used real review heads with multiple commits and normal merges. The way a clean pull request model works, but with the automation we want.
It is entirely possible to write a review system that integrates with git, stores all commits for review inside of the repo, does not use rebases, supports multiple commits in a review-head without making buggy commits part of the main line of master, support post-commit review as well, and doesn't fight git introducing ugly hacks or making non-git things do things git is supposed to be doing.
And if I had the time (ie: backing) I'd write it.