On Thursday 18 November 2010 18.18.25 Niko Sams wrote: > 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/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 _______________________________________________ Kde-scm-interest mailing list [email protected] https://mail.kde.org/mailman/listinfo/kde-scm-interest
