On Fri, Feb 12, 2010 at 07:30:56PM +0100, Riccardo Iaconelli wrote: > On Friday 12 February 2010 18:52:43 Oswald Buddenhagen wrote: > > - one should not have to resort to a different repository to actually > > checkout an older version. you can't do that with a subtree merge. > > is it really such a frequently used feature? i think this is really a minor > thing. > it might be interesting for those who track both branches.
> > - the actual data should not be duplicated. the repositories will be > > large enough as is. that's the antithesis of a subtree merge. > > how big would the real impact be? i agree this is a problem if it gets > too big, I'm just trying to get realistic ideas based on realistic > data. > i don't know. a few tens or hundreds of megs if one discards the histories of playground and kdereview in the first place. > Of course I think we should be wiser in the future once we know about > this limitation and not put the whole oxygen icons in kdelibs. :-) > a good start would be agreeing that the problem already exists (and will become visible after the git migration) and splitting the modules intelligently in such a way that the impact is as small as possible. > > i can remember more: > > - git speed > > Sure, it will be slower. However, I used it for years on modules as big as > kdelibs or kdebase, and never had a problem, it just hangs a bit the first > time (~20 secs), but it's still very bearable. Do you think it's a real > problem? > it's annoying, in particular for those who do occasional changes here and there, i.e., don't have everything in ram all the time. also, rebasing is very cpu-intensive and dependent on the repo size. > > - merge conflicts > > - side effects of fixing history > > What do you mean? > please read the archive for the answers. _______________________________________________ Kde-scm-interest mailing list Kde-scm-interest@kde.org https://mail.kde.org/mailman/listinfo/kde-scm-interest
