[Kde-scm-interest] atomicity, again

[Ian Monroe]

2009/6/16 Boyd Stephen Smith Jr. <bss at iguanasuicide.net>:
> In <200906152027.47623.thiago at kde.org>, Thiago Macieira wrote:
>>Boyd Stephen Smith Jr. wrote:
>>>In <200906151757.53601.thiago at kde.org>, Thiago Macieira wrote:
>>>>Jeff Mitchell wrote:
>>>>>Thomas Capricelli wrote:
>>>>>> http://www.selenic.com/blog/mercurial/sharedandsubrepos.html
>>>>>Git has a similar feature (submodules).
>>>>Git submodules work fine for what they're meant to be.
>>>>Reading the link above, it seems that Mercurial's solution is exactly
>>>> like Git's.
>>>Odd, I read the link, and it seemed as though commit command(s) in
>>> Mercurial would recur into subrepositories and perform a commit there
>>> and then use that new commit id for updating the "parent" repository.
>>That's not the problem.
>>
>>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*.
>
> To do that 100%, it seems like you'd need some sort of two-phase commit
> and/or ref locking.  It seems like *most* of the time though, a script that
> fetches all the refs you are pushing to and making sure all updates are ff
> and, if so, performing all the pushes would work 95% of the time for all but
> the most active groups of repositories.

Well we don't need any tools at all to get sort-of atomicity. :) Both
of these tools are for tracking external projects, not organizing a
metaproject like KDE.

Android's repo is an interesting tool, but it does more then just
download several projects at the same time, its tied into their review
system etc. I think KDE could make due with a fairly limited tool.
Though Thiago thinks we should have a 'kdemultimedia.git' (not sure
what I feel on it), if we had something like that there wouldn't be
much of an issue at all.

Ian