[Kde-scm-interest] Package splitting

[Thiago Macieira]

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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
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