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

[Friedrich W. H. Kossebau]

Am Samstag, 2. Juni 2012, 08:28:25 schrieb Friedrich W. H. Kossebau:
> Am Freitag, 1. Juni 2012, 00:33:13 schrieb Friedrich W. H. Kossebau:
> > Hi Ian,
> > 
> > Am Montag, 28. Mai 2012, 18:22:52 schrieb 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.
> > 
> > Good to read :)
> > 
> > > > 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.
> > 
> > Okay, so will do that for those utils as well, move them down one level
> > into a new toplevel dir kdesdk/utils soon (going to be next sunday).
> 
> Hm...
> 
> So I was going to move manually all those small utils to a new dir
> kdesdk/utils, but only in trunk.
> 
> But now I wonder how will this solved for all the branches, where the small
> utils will be in their old place when the migration rules are run.
> 
> Wouldn't it just complicate the rules if I do the moving now manually
> already in trunk? So would we better let the rules do that move in all
> branches?

Talking more to myself...

I guess a better solution would be to not move anything now, but instead 
create the repo with the utils directly from the existing module, as if the 
module only consists of those submodules that should end up in the kde-dev-
utils repo. After all that repo will have the same directory layout (incl. 
doc/kmtrace) as the module has now in subversion, modulo those submodules that 
are split into their own git repo.
And as there is only one collection repo this also would not conflict with the 
current work to make the submodules (=future repos) self-contained: all those 
submodules would be listed with "add_subdirectory(...)" at the begin of the 
toplevel CMakeLists.txt, while the rest of the file would be transformed to be 
the future toplevel CMakeLists.txt of the kde-dev-utils repo.

Would that be a suitable approach?

Anyway I need to learn about rule-writing now...

Cheers
Friedrich