[Kde-scm-interest] atomicity, again

[Johannes Sixt]

Boyd Stephen Smith Jr. schrieb:
> In <200906152027.47623.thiago at kde.org>, Thiago Macieira wrote:
>> The problem happens when you try to push your nested sub-repositories to
>> upstream servers. If one of them fails to push, you have to rebase or
>> merge, which means the SHA-1 of the commit changes. And then you have to
>> update the link in the parent repository.
>>
>> When you push the parent, then maybe that one fails as well to push. You
>> have to merge and that may cause conflicts (maybe someone pushed an update
>> to the repository you've just pushed and got to the parent before you
>> did). You have to fix that manually as well.
> 
> Oh.  Now I get it.  I'm just used to the git idea of a commit being a local 
> operation.  So, using git/hg terminology, we would like an atomic cross-
> repository *push*.

That this problem exits at all only shows that the intent that literally
hundreds of people have push access to the same repository is flawed. But
I know that I fight windmills :-(

A compromise would be that push access to the KDE superproject is limited
to only few people so that non-fast-forward pushes cannot happen so
frequently. IOW, atomic cross-repository commits can be pushed only by
those few people. This would mean that when (eg.) I have to make an atomic
cross-repostory change, then:

1. I push the changes to my own public repositories;
2. ask one of those few (eg. "BD") to pull.
3. BD would merge with upstream (so that the pushes are fast-forwards);
4. BD would push the result;
5. BD would make the superproject commit and push that as well.

-- Hannes