[Kde-scm-interest] Sysadmin advice regarding Monolithic vs Split repositories.
kdemailinglists at bethselamin.de
Tue Sep 7 22:50:15 CEST 2010
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
More information about the Kde-scm-interest