[webkit-dev] An incremental approach (was Re: UPDATED Re: Version control survey)

[Alp Toker]

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 
commit-queue at webkit.org, 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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-dev/attachments/20120310/976ee6c2/attachment.html>