[TYPO3-commerce] Reminder - poll about SVN vs Git

[Jigal van Hemert]

Hi Karsten,

On 1-7-2011 10:49, Karsten Dambekalns wrote:
> By now I think you simply personally don't like git (which is ok, I
> don't svn) :).

Honestly, I was looking forward to using git. I read about the 
theoretical basics, about how complex development models could be 
maintained with a few operations, etc.
It was only after the first attempts to actually *use* git / gerrit that 
I encountered all the problems.

> Anyway, I'll try to respond to some of the things I think are not "true".
>
> On 15.06.11 10:33, Jigal van Hemert wrote:
>> - yet another place for discussion (besides bugtracker and
>> newsgroup/mailinglist)
> No, Gerrit replaces the mailing list when it comes to RFC, no thing
> additional here.

Previously developers read the mailing lists / newsgroups and one of the 
things they subscribed to were the RFCs which were posted by others. You 
still have to read the mailing lists there is actually an extra place 
you have to visit.

Gerrit isn't particularly suitable for discussions. If a review requires 
discussion this has to be continued either in the bug tracker or the 
mailing list. Unfortunately the bug tracker doesn't support threaded 
discussions; very hard to keep track which post is a reply to which post.

>> - new patches, new versions of patches and reviews/comments are not
>> pushed to the newsgroup but you have to actively look them up in gerrit
>
> I also have to actively fetch news. And *gasp* read them. If you want
> mails, set up a watched project and enable mail notification in Gerrit.

As you very well know Gerrit sends notifications as separate messages 
and your favourite mail client cannot construct threads from them

>> - gerrit lacks options to categorize / tag changes
>
> Well, topics come to mind here. What else do you need? Maybe a feature
> request to Gerrit can help. Also I usually star changes I keep an eye
> on, depending on the situation (sometimes it means "cherry-picked
> already", sometimes "get back to this", as needed).

Mail and news clients often allow you to categorize or tag threads and 
messages with custom labels. In the old core list I used various labels 
to mark RFCs for things like "need to test", "reviewed, waiting for 
second vote", "need to submit", "for next release", etc. My mail client 
has the option to filter these with a single click.

Maybe this can be added in future versions of Gerrit, but currently it 
only has "starred" items.

>> - all reviews/comments are grouped by version of patch ("change set"),
>> it lacks a way to respond to a particular review
> Nothing beats answers to inline comments in diff view, when it comes to
> that IMHO.

Inline comments are nice for "discussing" a single line of code. If it's 
about an algorithm, general approach, test results (performance, etc.) 
you could use the review. For more discussion you have to refer to 
either a mailing list or the bug tracker. Fragmentation again.

Both the inline comments and the reviews in Gerrit lack threading (a 
tree structure for discussing things)

>> - a new version of a patch (even if only the commit message changed)
>> results in loss of votes
>
> Which is good, because it forces you to actually check what was changed.
> If the change was trivial, just mention you kept earlier votes in mind
> and give +2/+2 to submit.

Whether it's good or not remains to be seen. Developers with +2 rights 
can be considered as responsible. They are very capable of judging if 
votes should be kept or not. Resetting means extra work to dig up the 
votes from previous sets.
This is just a small issue however.

>> - if patch cannot be applied automatically (at first gerrit could not
>> apply a patch to a file if that was modified by another patch (fixed in
>> configuration), now there are problems when a submodule is introduced
>> somewhere else in the source tree) the patch has to be fixed, pushed
>> again and review/submitted again (instead of just fixing it before
>> committing to svn)
>
> Ever tried to change svn:externals? No? Yes? Not less trouble. As to
> "just fixing before commit", see above on loss of votes.

As a contributing developer (not maintaining the central repository) I 
never experienced problems with svn:externals; I am not sure if anything 
changed during the last couple of versions of TYPO3.
I think that the new Extension Manager was also added as an external 
during development of 4.5, but there was never a patch (for something 
which had nothing to do with the EM) which couldn't be applied.

With git/gerrit a patch seems to be a snapshot of the repo at the time 
of pushing it. Recently some submodules (a bit like svn:externals) 
changed (they were added) and thus patches completely unrelated to them 
cannot be fetched without having to re-initialize the submodules in your 
local repository.

It's probably because git is much more powerful, but I fail to see the 
reason why for example a patch in t3lib_div cannot be applied when 
extbase is added as a submodule.

>> - with git you can work on different things more easily because you can
>> create (local) branches for each task. If you are not comfortable using
>> git (i.e. you're not a git expert who can easily fix problematic
>> situations) this is quite scary. You have to trust git to store your
>> work correctly.
>
> I also had to trust svn, and that was harder. svn broke for me multiple
> times in the past (the scary way of breaking, where you had to mess with
> stuff inside .svn/soemthingbinary). With git I had no such problem so far.

I assume that you are talking about the central repository. For the 
developers who only deal with their local repository svn was less scary. 
If all went completely wrong you started with a new working copy.

It happened several times that I couldn't fix the errors I encountered. 
The only solution: ask for help in a newsgroup and wait for the 
solution. The time I had available that day was not spend on TYPO3 
development.

>> With svn you create patches to store work and revert the changes. You
>> could easily delete the working directory and checkout the repository
>> again and still have the patches.
>
> What keeps you from doing this with git? On the contrary, with git you
> can even keep commit messages, authors and committers in a patch.

Nothing keeps me from doing this with git, but it was advertised that 
branches were the wonderful replacement for this.

If I wont use branches, what are the advantages for developers?

>> - although there are GUI tools for git, there is virtually no support
>> for them from the git experts in the community. Especially for Windows
>> GUI tools you are on your own (I'm sorry to say, but a couple of them
>> have explicitly refused to take a look at them). Make sure you're a
>> command line fan and like things such as bash, vi, etc.; then you may
>> like git too.
>
> Wrong. The problem is twofold. First, most GUIs simply replicate CLI git
> via buttons, no gain as such you still need to understand git. The only
> exception so far is the new "Github for Mac" client release some days ago.

Not my opinion. GUIs help you with the correct syntax (just like an IDE 
helps with syntax, code completion, etc.), shows the situation of the 
various available branches in the log, has nice tools for cherry picking 
(instead of editing a text file), graphical representation of branching, 
merging, etc., integration in OS (icon overlay for status of a 
file/directory, context menu (e.g. blame for a single file)), add 
unversioned files by marking them in a list, etc.

Of course this can be seen as a graphical shell around git, but that is 
true for any GUI.

> Second, sorry, taking this slightly personal, when it comes to refusing
> support for Windows users from my side: I have no Windows, I have no
> clue about Windows. SmartGit is available for Windows, Linux and Mac and
> is the same thing all across. Surely someone uses it and could help you.

As far as I understood a team was formed for the transition to 
git/gerrit. IMO this team should have paid more attention to supporting 
the developers with using git/gerrit in the various OSes/environments. 
The simple fact that the team members use a mac and love the command 
line does not mean that this should be forced onto others or just leave 
them on their own.
We tried to use SmartGit on Windows in Berlin, but it couldn't find the 
installed Git. TortoiseGit installed without a problem and recognized 
the Git installation immediately. It is very similar to TortoiseSVN in 
colour highlighting, conflict editor, etc. One thing it doesn't support 
yet (there is a change pending for it) is checkout FETCH_HEAD. It would 
have been nice if the git/gerrit team would have taken the time (e.g. in 
Berlin) to sit with one of the Windows users and figure out how to use 
TortoiseGit with Gerrit.

Why such an effort? Simply because we need more contributors to TYPO3. 
In the past it was rather easy to figure out how to make a patch and 
send it to the core list, but with git/gerrit things are not that simple 
anymore.

And the proof that we all should worry about that comes from Ben's 
community report [1]. Although it is not possible to find a direct 
relationship with the decreased activity and the use of git/gerrit, both 
started around the same time. It suggests that the two events have 
something to do with each other.

My personal impression is that the "efficiency" of Gerrit and moving 
away from the Core mailing list has taken the community feeling away. 
The contributing developers virtually came together in the mailing list. 
New RFCs and reviews were there for grabs. In Gerrit there are just 
change sets and the personal part is missing.
I have no idea how to bring that back with Gerrit. Maybe if the whole 
structure would be more like discussion platform with threaded 
discussions where voting was an option? If it had personal categories / 
tags for threads and/or postings? A normal search box (the search help 
doesn't give me a clue how to search on one or more words), easy 
sorting, ...

TYPO3 is a community product and most of the developers are attracted by 
the community feeling. Apparently the lack of this feeling has resulted 
in a decreased activity.

> Plus: *noone* helped me to get into git. If that makes me an expert that
> has to help everyone else, I better stop learning new things.

I had the impression that you were one of the people who initiated the 
move to git. If you are somehow interested in thoroughly knowing git 
then that is fine for you. Most of the developer just have to use it as 
a tool to make and test patches. I personally feel that such a tool 
should be easy and should not require reading an entire book.

If you are one of the 'team' (how formal or informal that is) who takes 
care of the move to git/gerrit then yes, it is part of your task to help 
the development gain momentum again.

I'm sure you don't mean this line in the way that I understand it, but 
it almost seems that you don't want to share your knowledge. That is 
certainly not in the spirit of TYPO3.

As a final remark: I don't hate git/gerrit per se. It's just that we 
only read general descriptions which basically call it the best 
invention since sliced bread: git is modern, powerful and gerrit is 
efficient. I just want to warn that the practical results for TYPO3 v4 
haven't been that positive so far.

[1] http://news.typo3.org/news/article/typo3-community-in-may-2011/

-- 
Kind regards / met vriendelijke groet,

Jigal van Hemert.