2009/6/16 Boyd Stephen Smith Jr. <[email protected]>: > In <[email protected]>, Thiago Macieira wrote: >>Boyd Stephen Smith Jr. wrote: >>>In <[email protected]>, 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 _______________________________________________ Kde-scm-interest mailing list [email protected] https://mail.kde.org/mailman/listinfo/kde-scm-interest
