[Kde-scm-interest] Sysadmin advice regarding Monolithic vs Split repositories.

Chani chanika at gmail.com
Tue Sep 7 22:03:28 CEST 2010


On September 7, 2010 09:04:40 Tom Albers wrote:
> Dear Scm-interest,
> 
> As promised, the people behind the sysadmin team would like to give advice
> regarding the monolithic vs split repositories issues. We have tried to
> stay away from the community/social issues and focus on the technical
> consequences such a decision involves - such as how to setup the different
> services we will setup.

thanks for the report. :)

I like the comment about rsibreak ;) there certainly are advantages to split 
repositories...

however, there are still some things I'd like clarification on:

-would moving a project between monolithic repositories really be all that 
bad? you say that the kdereview workflow would "no longer be possible" - but 
iirc, we were told before that moves would be possible, merely harder.
What I'm concerned about here is plasmoids: even if we go for split 
repositories for apps (which I agree would make for a much easier and less 
surprising kdereview workflow), it may be a bit excessive for every little 
plasmoid to have its own repo.
Perhaps for little plasmoids (and other odds and ends that will inevitably 
crop up) we could move them and leave/copy their history?

-you mention pros and cons of monolithic, but not split repos... perhaps these 
are just two sides of the same coin, but I'd like some more detail on the 
disadvantages of spilt repos.

-I don't understand the fuss over reviewboard. currently, reviews are sent to 
groups, independent of where the code is located: for example, a plasma review 
request could be for code in kdelibs, workspace/plasma, kdeplasmaaddons, 
playground, or elsewhere. Are you suggesting automating (and therefore 
changing) these reviewer groups, or just the underlying modules? (I would 
assume the latter, but want to be clear here :)
Also, 90% of the reviews are old cruft that someone forgot to close, so imho 
you'd have no problem just discarding them when a move happens. :) anything 
that's not abandoned could be resubmitted.

-can the namespacing be set up so that someone could one day write a patch to 
redmine to hide redundancies in naming? :) that'd be a nice touch.

-how does each option affect release engineering and packaging? I don't see 
that addressed anywhere in here. :/




More information about the Kde-scm-interest mailing list