[Kde-scm-interest] atomicity, again

[Thiago Macieira]

Ian Monroe wrote:
>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 like I said, I don't think this is a problem. It exists in the 
theoretical sense, but I don't think it applies to us.

SVN has a solution for this problem, yet we don't use it properly. And it 
doesn't solve the more complex issues, like adding an API in kdelibs, 
using it in kdebase, then changing the API again.

In any case, supermodule commits aren't necessary except periodically to 
update and for those few circumstances where synchronisation is required 
(for future reference). For daily builds, it doesn't matter: if something 
fails, just pull again and try again.
-- 
  Thiago Macieira  -  thiago (AT) macieira.info - thiago (AT) kde.org
    PGP/GPG: 0x6EF45358; fingerprint:
    E067 918B B660 DBD1 105C  966C 33F5 F005 6EF4 5358
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part.
Url : http://mail.kde.org/pipermail/kde-scm-interest/attachments/20090617/c5f69840/attachment.sig