[Kde-scm-interest] RFC: git move proposal; "duolithic" kdegames
Stefan Majewsky
stefan.majewsky at googlemail.com
Wed Mar 2 23:31:12 CET 2011
[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.
Greetings
Stefan
More information about the Kde-scm-interest
mailing list