On Wed, Jan 27, 2010 at 03:07:45PM +0100, Thiago Macieira wrote: > Em Quarta-feira 27 Janeiro 2010, às 14:46:21, Oswald Buddenhagen escreveu: > > 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. > > > > > > > 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. > > I don't think updating the supermodule is necessary. > > What gain do you have here? > as i said a few mails before. that the supermodule would force a minimal sha1. i don't know whether it can be currently done, but it should be doable.
> > 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. > > That's why we have "Binary Incompatible Mondays" for. > yes, i considered that. but i must admit, i find them quite a pita to adhere to personally (though that would be significantly reduced by pervasive use of git). and other projects with shorter dependency chains might want a shorter cycle - but at some point it simply becomes ineffective. > > 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. > > Doesn't need to be sha1. Libraries have version numbers. We just have to have > room in the numbering to increase it when necessary. > yes, but nobody *wants* to maintain micro-version information ... depending on sha1s would limit the pain to the "consumer" side, but that's still painful. _______________________________________________ Kde-scm-interest mailing list Kde-scm-interest@kde.org https://mail.kde.org/mailman/listinfo/kde-scm-interest