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

[Richard Dale]

On Wednesday, September 08, 2010 05:43:56 pm 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.
We haven't had a discussion yet on the kde-bindings mailing list, but I 
forwarded Tom's mail to the list with this comment:

On Tuesday, September 07, 2010 07:25:29 pm Richard Dale wrote:
> FYI
> 
> Here is the sysadmin's view of how svn modules should be mapped onto git
> projects. I really think this is what we need for kdebindings. We still
> want the common infrastructure of this mailing list, the #kde-bindings irc
> channel and common release schedules, but with finer grained git repos.
> Perfect in my opinion!

We need to split the modules and make the Qt-only parts build without KDE 
dependencies, at the same time as allowing the Qt-only parts to be built with 
KDE dependencies in another branch.

-- Richard