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

[Ian Monroe]

On Thu, Nov 18, 2010 at 4:16 AM, 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.
> 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?
> 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.
>
> 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.
>
> /Regards
> Torgny

Which option do you think makes it the easiest to track a given file
though history? From what you say it sounds like option #1. I think
being able to give an easy answer to "hey, when did this code get
here" is the most important thing. Accuracy is secondary, since we can
keep SVN in storage somewhere for that.

But as Niko points out, if the module opts to be split then the
question is somewhat moot.

Ian