From kde-scm-interest  Mon May 28 16:22:52 2012
From: Ian Monroe <ian () monroe ! nu>
Date: Mon, 28 May 2012 16:22:52 +0000
To: kde-scm-interest
Subject: Re: [Kde-scm-interest] KDESDK->git: joining submodules in a single repo?
Message-Id: <CAHh0A5Ww_o+o6wFCUQ0Ei0O9jprkcRHoWmM5CL1QfZB+LontJQ () mail ! gmail ! com>
X-MARC-Message: https://marc.info/?l=kde-scm-interest&m=133822235909992

On Mon, May 28, 2012 at 5:22 PM, Friedrich W. H. Kossebau
<kossebau@kde.org> wrote:
> Hi,
>
> currently it is planned to split the kdesdk into several git repos.
> Just, the split would not simply be done by the existing submodules/toplevel
> dirs.
>
> While it would be simple for all the big programs (umbrello, kompare, etc.)
> and plugin types (dolphin-plugins, strigi-analyzer, etc), which would be
> directly mapped to an own repo, the plan is to join in a single repo all those
> small utilities for developers using...
> ... KDE libs/framework:
> * kpartloader - program loading kparts
>
> ... Qt libs/framework:
> * kuiviewer - program displaying UI files
> * kprofilemethod - C++-header for profiling using QTime
>
> ... X libs:
> * kstartperf - program measuring startup time using preload of XMapWindow()
>
> ... C++(/C?):
> * kmtrace - program for malloc debugging using glibc's "mtrace"
>
> Has this, splitting into repos, but joining some of them in one submodule,
> been done in one of the other module migrations? From a quick look I could not
> find anything similar so far.
>
> If there was, how was this done?

What your proposing doesn't actually add any complexity to doing the
SVN->Git. So it's fine.

> I am asking especially with regard to prepare the buildsystem (good Sebastian
> added this). Is it as simple as just creating a new toplevel directory and
> moving the toplevel dirs of the utils listed above into that new directory, so
> that all the toplevel dirs again map 1:1 to the planned git repos?

Yep. This is what we did with KDE Bindings, since it was basically the
move to git which gave an excuse for a directory and build system
reorganization/refactor.

> If so, does anything outside the module depend on the layout/structure of the
> submodules, so that needs to be taken care of as well? Or is everything
> generated automatically from what there is in the module, so it also adapts
> automatically?

Nothing is automatic.

> Currently I cannot think of anything. Files should be installed as before and
> all translation catalogs should be named as before (does the actual location
> where they are generated matter?). API dox is also autogenerated completely
> from what files are found. And the submodules moved also do not have anything
> in doc/, so no problem there as well. What is missed in this list.

Well care should be taken with everything on the list.

Ian
_______________________________________________
Kde-scm-interest mailing list
Kde-scm-interest@kde.org
https://mail.kde.org/mailman/listinfo/kde-scm-interest