Ian Monroe schrieb: > On Wed, Jun 17, 2009 at 1:10 AM, Johannes Sixt<[email protected]> wrote: >> 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.
As long as you look at individual repositories, there cannot be atomicity. Atomicity is achieved only by hooking individual repositories under a parent project and then by looking only on that parent project. Perhaps you think of "atomicity of when commits are available for others to fetch". But this cannot ever work, because a push or fetch operation must count as "looking at an individual repository". Atomicity can only be achieved on the commit level. Within a single repository, each commit represents an atomic state change, by definition. In order to achieve an atomic state change across repositories, git offers submodules. ...o--o--Al--o-...-o--Bl--o--o kdelibs.git ...o--o--Ab--o-...-o--Bb--o--o kdebase.git ...------Ap----...----Bp KDE.git KDE.git is the parent project with submodules kdelibs.git and kdebase.git. Let's assume that the commit Ap in KDE.git recorded the states Al and Ab of the two submodules and that state was consistent. Developement in kdelibs and kdebase continues independently. Here let us assume that all commits between A* and B* are mutually "compatible"; therefore, atomicity is not needed. Then I come along with my changes Bl and Bb, which are dependent. I ask BD to create Bp in KDE.git[*] so that there is an official record that these two revisions must be used together. This is where atomicity across repositories is achieved. Of course, if BD (or I) pushes Bl to the public repository long before Bb (and Bp) is pushed, then someone else who happens to fetch Bl without Bb and builds on top of Bl is screwed. And the reason for this that kdelibs.git was treated independent from KDE.git. [*] I will not push to the public kdelibs.git and kdebase.git (because that would screw others), but I push to my "private" public repositories instead and ask BD to pull from there in order to create Bp. It's BD's task to push B* in quick succession, but it still cannot be guaranteed that every observer will see either both Bl and Bb or none of them. Only the time window can be reduced. > 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. Fortunately, that's true. > 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. Absolutely. -- Hannes _______________________________________________ Kde-scm-interest mailing list [email protected] https://mail.kde.org/mailman/listinfo/kde-scm-interest
