[Kde-scm-interest] Re: git repo of kdelibs

Niko Sams niko.sams at gmail.com
Thu Nov 18 18:18:25 CET 2010

On Thu, Nov 18, 2010 at 11:16, Torgny Nyblom <kde at nyblom.org> wrote:
> On Thursday 18 November 2010 10.24.20 Niko Sams wrote:
>> On Thu, Nov 18, 2010 at 09:07, Cornelius Schumacher <schumacher at kde.org>
> wrote:
>> > Is there an experimental git repo of kdelibs already somewhere? Nothing
>> > to actually work with for developing kdelibs, but just the kdelibs SVN
>> > module in form of a git repo for some experiments.
>> Hi,
>> You can clone that one:
>> git at huey.kde.org:nsams/test-complete/KDE/kdelibs
>> I ran the conversion about two weeks ago using that rules file:
>> http://gitweb.kde.org/kde-ruleset.git/blob/396176a0d4c3a0d23ca17094c31afdcc7
>> ddcd04c:/kde-rules-main
>> a quick look showed no obvious errors.
> That depends on what you are aiming at.
Ok, I should have written a bit more...
The rules are for split kde modules, ie. one repository per application.
kdelibs is just as it's in the kde-ruleset master branch.
kdepimlibs and kdepim I simply ignored (the rules are still there tough)

> After a quick look at those rules I get the impression that they ignore any
> history a submodule/lib/app has had outside the module they currently live in,
> or atleast put that history in a different repository?
This is true for kdelibs but not for the other modules. I tracked the
origin of every
application back to kdereview, playground or kdenonbeta. I also tracked moves
between modules.
(I'm sure I missed some)

> Also they seem to cut history for quite a few of the apps they match in
> kdereview as the commit that deletes them there most likely will delete the
> entire master branch for the coresponding repository.
No, svn2git does detect that as a move and creates no commit for it,
if the whole
application got moved. Unfortunately there was a bug in svn2git that
didn't detect
that move correctly and that resulted in a history you describe.
I fixed that bug in svn2git, but the conversion server doesn't have
the updated version

> For kdepim we have three options for how the conversion should be done
> (descision has not been made yet)
> #1 "Flat history": Each submodule/dir is followed as it is right now in HEAD,
> ie if a submodule was merged from a branch then the history of that submodule
> in trunk is lost for the duration of the branch. This seems to be how most
> people have converted atleast the single application migrations so far.
> #2 "Branch history": History is keept as close to the original history as
> possible, ie branches are branches. but not all are complete in the git sence
> as they might just contain a single subdir.
> #3 "Pure module history": Any time a submodule has spent outside the current
> module is discarded.
> The most attractive option (atleast to me) is #2 but "git log" has trouble
> following history due to a bug that makes it loose parent commits somehow.
> However "git gui blame" follows history correctly.
> Due to this (and perhaps the young age of some pim modules) option #3 is more
> or less out for pim.
> I think it would be nice if more peolpe could give there input on what they
> persive as the best alternative and then we should strive for using that
> accross the entire KDE code base.
When going the split, per app repository, approach, it's much simpler, as there
happens no app moving in and out. (except maybe plugins sometimes)
Option #1 sounds best for that.


More information about the Kde-scm-interest mailing list