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 _______________________________________________ Kde-scm-interest mailing list [email protected] https://mail.kde.org/mailman/listinfo/kde-scm-interest
