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

Friedrich W. H. Kossebau kossebau at kde.org
Sat Jun 2 06:28:25 UTC 2012


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?

Cheers
Friedrich


More information about the Kde-scm-interest mailing list