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

[Stefan Majewsky]

On Tuesday 07 September 2010 22:03:28 Chani wrote:
> 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?

It might be beneficial to adopt the monolithic approach here at a small scale. 
Applets are quite small in code usually, so you could also choose not to do 
any repo moving at all, and implement new applets in a work branch of the 
normal repository, instead.

For example: Suppose there is a repo "plasma-applets-clocks" which contains 
dozens of different clock applets. Now someone comes up with a new type of 
clock, and wants to write a new applet. He checks out "plasma-applets-clocks", 
creates a work branch, writes the new applet, and, when the work is done, asks 
for the branch to be merged (via ReviewBoard, I suppose).

Of course, on the large scale, we're running into the same problems as with 
monolithic repos in general. Distributing e.g. ~100 applets in e.g. a dozen of 
repos induces a categorization. What if it turns out that the categorization 
was suboptimal?

Greetings
Stefan