[Kde-scm-interest] atomicity, again

[Boyd Stephen Smith Jr.]

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.
-- 
Boyd Stephen Smith Jr.           	 ,= ,-_-. =.
bss at iguanasuicide.net            	((_/)o o(\_))
ICQ: 514984 YM/AIM: DaTwinkDaddy 	 `-'(. .)`-'
http://iguanasuicide.net/        	     \_/

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: This is a digitally signed message part.
Url : http://mail.kde.org/pipermail/kde-scm-interest/attachments/20090616/a1705e3b/attachment.sig