[Kde-scm-interest] Sysadmin advice regarding Monolithic vs Split repositories.

[Maciej Mrozowski]

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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part.
Url : http://mail.kde.org/pipermail/kde-scm-interest/attachments/20100908/9d5c3251/attachment.sig