[Kde-scm-interest] Re: [Kde-games-devel] Re: RFC: git move proposal; "duolithic" kdegames

[Parker Coates]

On 2011-03-03, Ian Monroe wrote:
> Single-project git repos really do make for easier repo management. It
> becomes more difficult to merge the stable branch into master the more
> people you have working on a project. For some projects that's just an
> inevitable problem associated with being large projects. But for
> kdegames this would be purely a contrived problem.
>
> So good reason for monolithic: you're a project like kdelibs or
> calligra with many inter-module dependencies. Developers might want to
> make a feature branches that affects several sub-projects at once. Or
> people not infrequently make cross-project commits. (The issue here is
> that there's no atomicity between separate git repos really.)
>
> Bad reason: cloning repos is hard!1
>
> True with the tools we have now its not as straightforward to checkout
> 'extragear' as it was before. But that really is a situation that will
> resolve itself (my personal goal is to find some cool way to fix
> create meta-repos with cmake). Kdeedu is splitting into 21 repos,
> kdebindings already has split into a bunch; kdegames wouldn't be
> alone.
>
> To me kdegames is a textbook case for split repos: you have a very
> simple dependency graph and largely independent projects, both
> technically and socially.

Personally, I've decided to support the "single application
repositories" cause. Having contributors check out the entire module
is a social goal, so I think it's reasonable to try to fix it
socially, instead of enforcing it technologically at the expense of a
cleaner workflow.

But really, that issue is orthogonal to the problem of large binary
files in git. Having two repositories per application is obviously a
bit extreme, but a shared svn module for data with per application git
repositories seems a bit strange as well (but that doesn't mean it's
not a good idea).

Has anyone from KDE really investigated any of the 3rd party solutions
that let git automagically store and retrieve large binaries to/from a
second (non-git) repository?

This is yet another reason why I'm in no hurry to migrate KDEGames.
There are a lot of tricky problems that I'd rather see others sort out
before we commit ourselves to a suboptimal solution.

Parker