[Kde-scm-interest] Sysadmin advice regarding Monolithic vs Split repositories.
George Goldberg
grundleborg at googlemail.com
Thu Sep 9 12:37:20 CEST 2010
2010/9/8 Ingo Klöcker <kloecker at kde.org>:
> On Wednesday 08 September 2010, Ian Monroe wrote:
>> On Wed, Sep 8, 2010 at 7:34 AM, Tom Albers <toma at kde.org> wrote:
>> > Again, we advise you to go for a split approach, if the list does
>> > not want that, it is fine. Just solve the problems we address in
>> > the document and accept the technical consequences it will have.
>> > To turn this around: don't discourage us to write such documents
>> > in the future, I think it contributes to the discussion and is
>> > therefore valueable.
>>
>> Well as already addressed, much of the issues listed in the document
>> are invalid since no one was ever proposing there literally be a
>> kdereview or a playground repo.
>>
>> Lets make this a bit more specific: what is the proposed hierarchy
>> for kdebase?
>>
>> Furthermore, since the KOffice folks always seemed to like to stay in
>> one repo to enable them to make commits touching multiple apps, would
>> having a single KOffice repo be possible? I understand this would
>> make Redmine a bit confusing, but treating KOffice as one Redmine
>> project isn't the end of the world.
>>
>> Personally I think the case for things like KDE Multimedia, KDE
>> Bindings, KDE Edu to each be a single repo is pretty weak. If partial
>> checkouts of a SVN repo are common, then the case for split repos are
>> quite strong. But things maybe get more complicated with kdebase and
>> koffice, for technical and cultural reasons.
>
> You can add kdepimlibs, kdepim and kdepim-runtime to the list of repos
> where splitting them into smaller repos doesn't really make much sense
> since they are so strongly intertwined. In fact, I don't see how the
> approach of split repositories makes sense for modules which have
> _internal_ libraries (kdepim is full of internal libraries) that are
> shared by several apps.
Reading this makes me realise that perhaps doing the same thing for
all modules is not appropriate. It sounds like the situation is very
different between the main-modules. One the one side, we have modules
like kdepim which have all the applications heavily intertwined, where
splitting seems like a bad idea. On the other hand, we have modules
like kdenetwork (where I have been working on the conversion rules)
which are just a set of applications with no connection between each
other, which would make sense to be split repositories. kdenetwork
contains Kget, Kppp, Krfb, Krdc and Kopete - all completely separate
applications (and at least KRdc can already be built standalone from
kdenetwork).
In summary, perhaps a one-size fits all approach is not what's needed
here. For example, a repository containing all of the Kontact suite
(kdepim) and separate repositories for the standalone applications
Kopete, KGet, KRfb etc.
--
George
More information about the Kde-scm-interest
mailing list