On Tuesday 07 of September 2010 18:04:40 Tom Albers wrote: > Dear Scm-interest, > > As promised, the people behind the sysadmin team would like to give advice > regarding the monolithic vs split repositories issues. We have tried to > stay away from the community/social issues and focus on the technical > consequences such a decision involves - such as how to setup the different > services we will setup. > > Our advise is to use a split repositories approach. > > The sysadmin team would like to setup the services real soon now, so we > ask this list to come up with a final decision about the setup. To be > clear: whatever you decide, we will implement it to the best of our > capabilities.
Thanks for investigation! I'd like to address some points, actually the one that monolithic layout breaks current application life cycle/workflow. It doesn't have to. Provided we forget about extragear or playground being actual repositories. If said places - playground, extragear, kdereview (or review) - are implemented as branches of corresponding ${module}, forward changing state of particular application is just merging between branches. Advantages: - moving forward (from playground->review, extragear->review, review->master) is easy, efficient, and preserves history (if it's considered advantage, I understand sometimes development history from playground for instance may not be welcome when app is moved to master) - (all mentioned monolithic module advantages like keeping current buildsystem, tarball packaging scriptsm tagging intact etc) Disadvantages: - moving app backward (master->extragear, master->playground, review- >playground, review->extragear) is less convenient with branches and probably implemented by the means of removing code (from master for instance) branching off to playground-${app} for instance, followed by immediate revert 'commit removing code' in that playground-${app} branch. - only one 'playground' or 'extragear' or 'review' item per ${module} so playground, extragear or review are essentially monolithic as well. This can be addressed by name sufix/prefix, for instance playground-kmail and playground-knotes in kdepim repo, but it means that all those playground-, extragear- branches are actually feature branches (slightly different workflow I suppose). Also multiple review branches possible here. - ${module} repository size grows with every global feature branch or review branch added, so purging some of them occasionally is needed (hardlinks should help here a bit) to make cloning repo nicer. -- regards MM
signature.asc
Description: This is a digitally signed message part.
_______________________________________________ Kde-scm-interest mailing list Kde-scm-interest@kde.org https://mail.kde.org/mailman/listinfo/kde-scm-interest