[Kde-scm-interest] Package splitting

[Oswald Buddenhagen]

On Wed, Jan 27, 2010 at 02:01:28PM +0100, Thiago Macieira wrote:
> Git submodule isn't atomic at all. It cannot be used to indicate atomicity 
> because it requires at *least* two operations (two pushes), any of which could 
> fail. In our case, it would require three: two submodules and the supermodule.
> 
> If we have split repositories, then we lose atomicity. Period.
> 
> This includes for example having kdelibs separated from kdebase. If someone 
> adds a new feature to kdelibs and then uses it in any application, that 
> already requires non-atomic updates.
> 
> And no one is suggesting making one huge KDE repository with everything in.
> 
> So forget atomicity. It's not an argument.
> 
indeed.

but i think that's non-critical for dependencies on "additive" changes,
as it is sufficient to commit the lib change first, then the supermodule
change and finally app change.

it becomes a problem if the change really needs to be atomic because the
lib change is "substitutive", i.e., breaks existing functionality. the
"pseudo-atomicity" would be still sufficient to eliminate most cases of
"update foolibs, sucker" cases, though.
btw, in theory, it is possible to split every substitutive change into
five additive/neutral ones: add improved version of class, make app use
new class, replace old class with new class, make app use old class,
delete new class. of course this is purely academical ...

> > 1) Interestingly; when we introduced cmake the atomicity of commits was
> > expected already. Typing 'make' in your app will cause cmake to compile
> > your libs dir first, as it depends on that.
> 
> That's not atomicity.
> 
> That's dependency tracking, done by CMake.
>
that's actually an interesting idea: one could have micro-versionchecks
(on sha1's) in the cmake files. however, updating them manually would be
a royal pita.