[Kde-scm-interest] Package splitting
thiago at kde.org
Wed Jan 27 14:01:28 CET 2010
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 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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 190 bytes
Desc: This is a digitally signed message part.
Url : http://mail.kde.org/pipermail/kde-scm-interest/attachments/20100127/ec9c2756/attachment.sig
More information about the Kde-scm-interest