On Thursday 18 November 2010 11.23.59 Ian Monroe wrote: > On Thu, Nov 18, 2010 at 4:16 AM, 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. > > 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. > > 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.
Well I guess the real question buils down do do people use log or blame to find where code originates from and should we take the opportunity to clean history? > But as Niko points out, if the module opts to be split then the > question is somewhat moot. Only if the app has been 100% self contained from day 1. /Regards Torgny _______________________________________________ Kde-scm-interest mailing list [email protected] https://mail.kde.org/mailman/listinfo/kde-scm-interest
