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

[Ben Cooksley]

2010/9/8 Maciej Mrozowski <reavertm at gmail.com>:
> 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.

This has a single, quite massive flaw: If the module selected when
commencing development of an application is wrong, say a developer
selects kdebase when kdeadmin is more appropriate, there is no way to
fix this whilst keeping the development history.

Also, the central application repositories will be much larger, which
is large already for some repos.

>
> 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.

We will also get the previously mentioned growth-over-time of the
repositories, which is not desirable as mentioned in the report.

>
> - 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.

What about abandoned applications here? We would need to flush and
totally rebuild these repositories every so often to keep the
repositories at an acceptable size.

It isn't possible to have multiple branches checked out at once
either, so developers would need to checkout the application branches
they wish to build, then merge in the application branches, which is
quite a messy workflow.

>
> - ${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.

Hardlinks will only save server space, not bandwidth as far as I know.

Even for those in relatively high speed, low cost internet areas, the
time taken to clone large repositories and the disk space consumed
will be a disincentive to clone the repository.

>
> --
> regards
> MM

Regards,
Ben

>
> _______________________________________________
> Kde-scm-interest mailing list
> Kde-scm-interest at kde.org
> https://mail.kde.org/mailman/listinfo/kde-scm-interest
>
>