[Kde-scm-interest] atomicity, again

[Johannes Sixt]

Ian Monroe schrieb:
> On Wed, Jun 17, 2009 at 1:10 AM, Johannes Sixt<j.sixt at viscovery.net> 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