Em Quarta-feira 27 Janeiro 2010, às 12:38:21, Thomas Zander escreveu: > 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.
I don't agree.
We're talking here about independent projects. Independent projects don't
depend on each other. So updating A without updating B should work.
Or we're talking about libraries. In the case of libraries (including
kdelibs), this is a matter of convention. If this works for kdelibs today, why
wouldn't it work for kofficelibs?
> 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.
I don't agree.
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.
> 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.
That's not atomicity.
That's dependency tracking, done by CMake.
--
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
Senior Product Manager - Nokia, Qt Development Frameworks
PGP/GPG: 0x6EF45358; fingerprint:
E067 918B B660 DBD1 105C 966C 33F5 F005 6EF4 5358
signature.asc
Description: This is a digitally signed message part.
_______________________________________________ Kde-scm-interest mailing list [email protected] https://mail.kde.org/mailman/listinfo/kde-scm-interest
