[Kde-scm-interest] Distributed model VS accountability

[Johannes Sixt]

Thiago Macieira schrieb:
> If I define the problem as "knowing who pushed what", then all we need is a 
> log of the server. So my first idea was to simply have a file in a separate 
> branch (out-of-history) that logs the ID of who pushed and the commit SHA-1. 
> Any commits between that ID and the previous logged one must have been pushed 
> by the same person at the same commit.
> 
> Pros: no change in the way we work.
> Cons: requires trusting the server, out of history (separate branch)

If this is all that you need to have accountability, then the easiest thing 
is to give every contributor an ssh account (with git-shell instead of bash, 
of course) plus the extra logging of login+SHA1 that you mention. Commits 
can still be forged, but the *push* cannot.

But I still don't see how a random contributor's commit ends up in a release 
in a DSCM scenario without a hierarchy of "lieutenants" and possibly a few 
"BDs" (Benevolent Dictators). Consider two developers who want to publish 
two independent fixes in the same module at the same time.

Centralized SCM, eg. SVN:

Both check out revision R. Developer A happens to get the first drawn and 
commits R+1. Developer B commits R+2, and was not required to check out R+1 
first because there were no overlaps. R+2 contains both fixes.

Distributed SCM, eg. Git (mimicking a centralized SCM):

Both check out branch 'master'. Developer A pushes his fix onto branch 
'master' into the repo. Developer B wants to push to 'master', but is 
denied, because his change does not fast-forward. So he must fetch again, 
rebase his fix on the new 'master', push again. If he's lucky and nobody 
else had pushed something in the meantime, he can ultimately push onto 'master'.

You see immediately that this workflow won't work out, in particular during 
times when dozens of developers are busily squashing bugs for the next release.

For this reason we had discussed private repositories and private branches. 
But any commits in such private locations will not end up in a release 
unless there is someone who collects them and cherry-picks them onto "the" 
release candidate branch, which could be 'master' of the stable/ repositories.

-- Hannes