[Kde-scm-interest] KDESDK->git: joining submodules in a single repo?

[Ian Monroe]

On Mon, May 28, 2012 at 5:22 PM, Friedrich W. H. Kossebau
<kossebau at 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