On Wed, Mar 2, 2011 at 16:31, Stefan Majewsky <[email protected]> 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 _______________________________________________ Kde-scm-interest mailing list [email protected] https://mail.kde.org/mailman/listinfo/kde-scm-interest
