On Fri, 10 Aug 2012 00:52:33 -0700, Marcin Cieslak <[email protected]>
wrote:
Daniel Friesen <[email protected]> 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.
--
~Daniel Friesen (Dantman, Nadir-Seen-Fire) [http://daniel.friesen.name]
_______________________________________________
Wikitech-l mailing list
[email protected]
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
