On Wednesday 27. January 2010 10.45.09 Thiago Macieira wrote: > You don't update the supermodule unless you want to say something. > > For example, when we're about to tag, tag all repositories, then the > supermodule. > > Other than that, there's no need to change the supermodule at all.
This is only true if you keep on thinking the way that subversion thinks. That it is ok that commits are not atomic. I've had too many accusations of breaking the build in koffice just because the user updated only his app and forgot to type 'svn update' in the libraries. The same happens on backports, though they tend to have a worse effect as those break it for everyone else too. Being able to update only the app and not the libs dir is possible because svn doesn't do atomic commits, and that causes confusion. If you, on the other hand, think its actually pretty useful to avoid this kind of problems[1] with the concept Git introduces of atomic commits then you'll see that the suggestion of using submodules is not as simple as Thiago writes above. You still need to change the supermodule a lot of times if you want to see it as a developer tool instead of a way to tag releases only. When I tried to develop with submodules I found them a real PITA, svn externals by comparison are a walk in the park. 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. -- Thomas Zander _______________________________________________ Kde-scm-interest mailing list [email protected] https://mail.kde.org/mailman/listinfo/kde-scm-interest
