On 10/03/2012 21:46, Maciej Stachowiak wrote:
In my opinion, the level of SVN use shown in both surveys indicates to
me that we should probably keep supporting it, unless most of the SVN
users would want to switch to Git. In particular, the second survey so
far is showing that SVN use is somewhat higher among committers and
reviewers than among the general population.
This raises an interesting point.
The repository at git.webkit.org is not so great to work with as a
committer / reviewer, and as Mark points out it's not too friendly on
the servers either.
As an incremental approach, it might be a good idea to first resolve
some of the issues in the mirror, including its layout and usability vs.
SVN.
Without this work being done, the benefit of git over svn is not so
clear to me.
The way I see it, a better mirror would address:
*ChangeLogs*
The ChangeLog entries in the git history mean every local merge, revert
or cherry pick is non-trivial, so you get an ugly non-linear history
whether or not you use a tool to auto-resolve ChangeLog conflicts.
Possible solution would be to do a new migration where the ChangeLog
entries are folded into the commit message the files themselves are
eliminated from the history, as if they never existed.
Maybe keep the original ChangeLog in an overlay branch for posterity,
since these files are sometimes hand-edited after the fact.
*Author Names
*The committer names don't have the full author name in the git mirror
right now, just an SVN id. This info could be extracted out of a
database or the ChangeLog message if one exists, during import. People
switch companies and email addresses over time, so that would have to be
accounted for.
This could go some way to alleviating Oliver's concern about inflation
in reviewer / committer population by corollary:
If the history is transformed to identify the author of an external
contribution in cases where the patch is landed by a reviewer or
[email protected], these guys would see their name next to their
work and get credited on places like Github and Ohloh.
Would result in less pressure amongst casual contributors to get commit
access, especially for those who care about the 'creds' or are doing it
to improve their CV to get a pay rise.
*Layout and repo size
*
The git repository with full history is enormous.
I don't really need the full history of every pixel test result for
every port, ever, including long-dead ports, and likewise don't really
want to pull it every time the expectations get updated.
It's not so much about disk space (everyone has plenty these days).
The bigger problem is that git grep and git pickaxe search through local
git history is so slow you actually end up having a better experience
using the search feature on Trac. One less benefit over SVN.
A proposal (or even better, proof of concept) for git repository layout
where the 'heavy' generated paths are split out into git submodules
separate from the source code would make me feel more comfortable with
the whole idea. Also, should be possible to do a shallow clone of these
yet still be able to commit and push back upstream (if git supports
this, git experts?)
I did some of the early WebKit git tooling but to be honest this is a
lot of work for someone to take on. But seeing some of the energy in the
debate, someone might be willing to have a go.
I do think that addressing these issues before advocating a switch would
strengthen the case, at least with reviewers who had a mixed experience
like mine.
Regards,
Alp
_______________________________________________
webkit-dev mailing list
[email protected]
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
