[Kde-scm-interest] Have we arrived to a dead end?

[Oswald Buddenhagen]

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.