[Kde-scm-interest] Re: kdegraphics libs migration

[Michael Pyne]

On Monday, December 27, 2010 18:45:57 Albert Astals Cid wrote:
> > Yes, this is a disadvantage of git, but we have to cope with that.
> 
> Yes, we have to cope with git disadvantages because it was forced on us
> that don't like it by the yous that like it, but i will still complain
> when I can since i think that destroying the development model we've used
> for ages because the SCM is not up to par with our requirements is
> something that seems like a bad idea.

Subversion is not magical. Every disadvantage that's been noted for git is 
something that is a disadvantage for svn as well. It happens that Subversion 
quite efficiently handles its operations (otherwise how would our repo with 
1.4 million+ separate entire changesets work?) but Git is quite efficient as 
well.

In fact given that we're moving to separate repositories instead of a giant 
SVN repo, there should be *much* less scaling problems already, so I don't see 
why an entire module could not easily be supported as a repository. After all, 
Git works just fine for the entire Linux kernel+drivers.

And as you've mentioned, kdepim was converted entirely, with the exception of 
kdepim/runtime.

So in other words let's not claim technical difficulties (and I realize you're 
not the one claiming this ;) for questions of how to lay out repositories. In 
my opinion, we should in general prefer to have larger repositories with 
collections of related apps/libs as we have previously had, for the reason 
you've mentioned, but also because it makes it much easier to actually get a 
working desktop.

e.g. with the kdesupport split individual components are each going to 
git.kde.org, so where it used to be easy to get all the "KDE-inspired-but-not-
KDE" libraries required from a single source, now it's practically required to 
look online to see what modules are required in order to make sure they're all 
built, and we end up with a ginormous dependency tree. This will eventually be 
worked-around with fancy XML (or something) but the dependency tree will still 
be just as large.

Obviously there's a balance that must be struck, but I think that for the most 
part the way we've *been* doing it has worked out well and should be the 
default as we transition to git.

Regards,
 - Michael Pyne
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: This is a digitally signed message part.
Url : http://mail.kde.org/pipermail/kde-scm-interest/attachments/20101227/94f73fe3/attachment.sig