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

[Ian Monroe]

On Wed, Mar 2, 2011 at 16:31, Stefan Majewsky
<stefan.majewsky at googlemail.com> wrote:
> [crosspost kde-games-devel + kde-scm-interest]
>
> Heya,
>
> I've been thinking about the Git move again. I'm still in favor of the
> monolithic approach for organizational reasons, e.g. I really like
> Aaron's argument that a single repo makes drive-by contributions from
> outside itch-scratchers easier. However, there is the problem with the
> huge size of the resulting repo. The important numbers are: 500 MB for
> kdegames with history, 108 MB for a current kdegames checkout, 80 MB
> of which are data files. I therefore propose:
>
> http://community.kde.org/User:Majewsky/kdegames_git_proposal
>
> The executive summary is:
> 1. A new module kdegames-data is created into which all binary data
> files are moved. kdegames-data is declared to have a build-time
> dependency on kdegames.
> 2. Applications are modified such that they can work without the data
> (as in: they won't crash). If that's not possible or not reasonable,
> simple dummy data files are included with the source code which ensure
> that kdegames can run standalone.
> 3. kdegames moves to Git while kdegames-data stays in SVN. Because the
> history of kdegames would include the data files and therefore nullify
> all the efforts, the kdegames Git repository starts from scratch with
> a simple source code import. The existing monolithic rules are used to
> create a kdegames-history repository which contains the history until
> the moment of the Git move.
>
> Taking aside the usual split-vs.-monolithic arguments, the only
> downside of the duolithic approach (as far as I see) is that it's
> impossible to create a 4.6 branch because the module layout changes.
> This will make backports to the 4.6 branch harder, but our development
> speed is fairly low compared to other modules, hence there are also
> very few backports (7 to the 4.6 branch at the time of this writing).
> If it really is too complicated or time-consuming for you, I promise
> to help with backports. The benefit from having a Git repository far
> outweighs this additional burden.

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.

Ian