On Thu, Nov 18, 2010 at 11:16, Torgny Nyblom <[email protected]> wrote: > On Thursday 18 November 2010 10.24.20 Niko Sams wrote: >> On Thu, Nov 18, 2010 at 09:07, Cornelius Schumacher <[email protected]> > 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: >> [email protected]: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 _______________________________________________ Kde-scm-interest mailing list [email protected] https://mail.kde.org/mailman/listinfo/kde-scm-interest
