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

[Niko Sams]

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
yet(?).

> 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.

Niko