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

[Niko Sams]

On Tue, Dec 28, 2010 at 00:11, Albert Astals Cid <aacid at kde.org> wrote:
> A Dilluns, 27 de desembre de 2010, Marcel Wiesweg va escriure:
>> > I read your mail and sincerely it seemed like "we screwed up with those
>> > libs and don't know what yo do, help!". Since i know nothing about git I
>> > can't help.
>>
>> I dont think we screwed up. Rules are written and repos look quite good. We
>> dont need help, I just want to talk about those libraries which we write,
>> need, maintain, and share.
>
> Good then sorry for misreading :-) Unfortunately i don't use any of those libs
> so don't have much input there.
>
>>
>> > If you ask what is my personal opinion as Okular maintainer
>> > i'd prefer a non split repo.
>>
>> Well, we went for a non-split repo with digikam et al and the answer from
>> sysadmins was pretty clear (monolithic a no-go). I've seen different
>> opinions on this list, but I can now, technically, only agree with the
>> split-repo approach: Why should one who wants to code a patch for gwenview
>> or libksane have to download okular's full history? Remember that git is a
>> bit different to SVN in that respect.
>
> The same question applies to SVN, why should one want to download gwenview
> code to code in libksane? The answer was because we were supposed to help
> eachother and more people downloading and compiling your code meant more
> people possibly being ready to help. But people helping eachother is an old
> fashioned way of thinking amonsgt KDE younglings it seems.
Downloading is not much an issue - you do it only once.
What more is an issue is that git looks for most operations at the
whole repository.
For example pulling with local (commited) changes: if you dont --rebase you
get a (useless) merge commit.
Or git log always shows the whole module history, tough you are only
interested into
onto application.
Or branches always branch the whole module, tough the branch is only ment for
one application.

Yes, this is a disadvantage of git, but we have to cope with that.

> Besides that philosophical rant there's a problem with okular, thumbnailers
> and strigi-anaylxer code that does ../../libs/mobipocket/mobipocket.cpp (yeah
> going back in your path outside "the project") and will obviously break if you
> do a split repo.
kdeedu has the exact same problem with libkdeedu.
The proper way to solve this with split repos is to install mobipocket and find
it using cmake. The lib must install headers and everything then.

The biggest problem I see is that you can't go back in history and
build stuff anymore.

Niko