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