On Wednesday 27. January 2010 14.01.28 Thiago Macieira wrote: > If we have split repositories, then we lose atomicity. Period.
Fully agreed. Guess why I'm against splitting modules. :) > 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. We are mixing things up here; Indeed nobody was suggesting to make one big repo. What we *were* talking about was splitting up things like kdegames and kdeutils. Going from the concept of having one module like kdegames *with* an included libs dir to having many git repos is more exactly what was on the table. The point of atomicity is a really useful thing there, people can develop on one game and pulling all commits has zero effect on compile time as he's still working on only that game. It does have the excellent side effect that if there was an update in the libs dir of that kdegames module cmake will trigger a recompile in the libs. Which is essential for development on the game itself too. > So forget atomicity. It's not an argument. In contrary; atomicity is the number 2 argument against splitting up the seperate kde modules. A counter argument that [some part in kde] doesn't have atomicity with [other part] would lead to it being perfectly fine to completely loose all atomicity falls under the bell-curve argument. It doesn't apply to the subject on the table. -- Thomas Zander _______________________________________________ Kde-scm-interest mailing list Kde-scm-interest@kde.org https://mail.kde.org/mailman/listinfo/kde-scm-interest