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 _______________________________________________ Kde-scm-interest mailing list [email protected] https://mail.kde.org/mailman/listinfo/kde-scm-interest
