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

[Torgny Nyblom]

On Thursday 18 November 2010 18.18.25 Niko Sams wrote:
> 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/396176a0d4c3a0d23ca17094c31
> >> afdcc7 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(?).

I have no idea as to the state of the conversion servers as i use my own 
server ;)

A big thanks for fixing this bug (guess I missed that).

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

If the app has been self contained I agree.

/Regards
Torgny