Daniel Friesen
<lists(a)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