[fpc-other] Git & SVN

[Karoly Balogh (Charlie/SGR)]

Hi,

On Tue, 23 May 2017, Marco van de Voort wrote:

> The problem is that if problems get practical the advocatists suddenly step
> back and aren't really able to do more than regurgitate either the standard
> beginner "wisdoms" or "you shouldn't want this" or "this is the new improved
> ways" or similar platitudes.
>
> To get get back on track, I'll restate the question I posed in the last
> message unambigously:
>
> how to avoid that a push of member X doesn't leave a branch in an
> undesirable state that leaves member Y three choices:

How to avoid that member X with commit write access doesn't leave a branch
in SVN in an undesirable state? :) You have to trust people, and choose
who you give write access to a given branch/repository, really. This
didn't really change and not an argument against git.

And well, in Git you don't push, but people who want to contribute, have a
pull request. Then you can review that, and either apply to your tree or
reject it. It's important to understand that in git all repositories are
equal, and that I have a "make-amiga-great-again" branch, doesn't mean
that you should have it, I could still send a pull request against your
master branch, or whatever branch. All pull requests are just a set of
changes, really.

> 1. push anyway and make the mess worse
> 2. hold the commit/push
> 3. clean the mess himself.

Well, ideally in distributed teams, people don't push, but have a pull
request. Basically as crazy as it sounds, everyone forks the project all
the time, but then you have a set of tools to reintegrate all those forks
easily. It's the responsibility of the maintainer of a given branch to
accept that pull request or not, or request further changes before its
accepted.

> In your own repository that is no problem, and even in companies this only
> takes only a few LART/cluebat applications to fix. However in distributed
> teams this is a pain.

No, it isn't. This is the primary problem git solves, actually, by making
it possible for everyone having their own sandbox to play with, and you
have a review filter before accepting changes. You can even sign off
changes by a maintainer, who reviews the code. All those messy branches
remain local if they're not approved, on the person's computer who messed
it up, they don't have to go global/upstream...

And talking about myself - as much as I enjoy just committing my crap to
trunk, I sometimes would really prefer review. Not because I'm not a
senior engineer, but especially because of that... Now if I don't want to
do a branch in SVN which are huge and expensive (Git branches are cheap
and small), I either have to commit it first anyway to trunk, then ask for
a review, or send a patch for review first in e-mail, which is quite
cumbersome. Plus there's absolutely no warranty, that I later commit the
same patch which was reviewed.

At work, I don't even push against master, but I do a pull request against
my own repository, and ask one of my senior colleagues to review... I
don't know about you, but to me this sounds a lot more like teamwork, than
going around beating up people "for wrongdoing" with a cluestick.

Of course in the end it's just like crypto - you need to have a chain of
trust from the top, a group of trustees who will do the actual merging of
the pull requests, reviews and then push it upstream/mainline/trunk. If
one of these maintainers do a bad job, then you need to sort out that
problem, but that doesn't mean the whole system is broken. It's similar to
giving commit access to a developer who doesn't deserve it in SVN, really.

Now, how the actual process would look with the FPC team, that's hard to
define at this point. But the tools are there for it.

Was this a proper answer, or I was beating around the bush in your views?
:)

Grmbhl,
--
Charlie