[Kde-scm-interest] atomicity, again

[Ian Monroe]

On Wed, Jun 17, 2009 at 1:10 AM, Johannes Sixt<j.sixt at viscovery.net> wrote:
> 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.

I really fail to see how any of this is atomic. And its not that big
of a problem anyways, especially since changes to kdelibs won't break
other apps until KDE 5 (at least not on purpose), which is like a >5
years away. And something being broken for some minutes doesn't matter
anyways.

And I'm pretty sure we're not going to let anyone do non-fast-forward
pushes (eg 'push -f') except maybe the sysadmin team in exceptional
circumstances. Anyone who works with a repo that has been push-forced
is pretty much screwed.

Ian