On Wed, Jun 17, 2009 at 1:10 AM, Johannes Sixt<[email protected]> wrote: > Boyd Stephen Smith Jr. schrieb: >> In <[email protected]>, 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 _______________________________________________ Kde-scm-interest mailing list [email protected] https://mail.kde.org/mailman/listinfo/kde-scm-interest
