[Kde-scm-interest] Meeting minutes

[Oswald Buddenhagen]

On Thu, Nov 12, 2009 at 08:23:54PM +0100, Thomas Zander wrote:
> On Thursday 12. November 2009 20.02.44 Oswald Buddenhagen wrote:
> > disadvantages of big repos:
> > - huge clones for everybody
> 
> "Huge" is a bit inaccurate, please provide numbers. (See ML history).
> 
like hundreds of megabytes? if i want just kcalc, why should i have to
check out everything which happens to have been lumped into the same
repository, including it's entire history? kde's idea of "modules" was
always one of the bigger contention points with the outside community
(in particular "yet-outside", i.e. potential contributors). driving it
to the extreme would not exactly help the situation.

> > - loss of history. 
> 
> Can you give a usecase where this is the case?
> Can you give statistics on how much we loose?
> 
not much to calculate here. the entire history before the last
cross-module move will be lost (or distorted). this affects every
application which entered the repo anytime recently, and everything
which was "promoted" to a more "central" module. the exact numbers don't
matter, we already know that it is non-trivial.

> Its good to have a voice of reason saying something is not perfect. I think 
> to follow up we should
> a) get an overview of the actual damage so we can decide if we want to
> do more work which leads to
> b) someone should do the work of splitting and of fixing a tool like 'repo' 
> to be useful for us.
> 
> point [b] is not trivial, but if you care for this issue you might want to 
> start now so we get a long way in the short time we have before the real 
> conversion.
> 
as i wrote in the other mail, there is no "if" anywhere here. it is already
blatantly obvious that we need *something* to manage a meta repository. the
granularity has no impact on the concept.

and before you ask (again): i have no resources to work on it. but i
sure will have the resources to start a revolution if a system which
introduces major regressions is forced upon me. ;)