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

[Chani]

On September 8, 2010 03:21:38 zander at kde.org wrote:
> On Tuesday 7. September 2010 18.04.40 Tom Albers wrote:
> > Our advise is to use a split repositories approach.
> 
> Reading the pdf I'm left with the impression that you guys didn't read the
> archives of the scm ML.  All of the disadvantages for a monolithic approach
> are incorrect and rebutted before.
> All the disadvantages to the split approach are also missing.
> 

yes, thanks for clarifying these points, tz. this is the sort of thing I was 
hoping to see in the report. (hmm, and I just realized a formal definition of 
monolithic vs. split would be nice - just how fine-grained would the split 
be?)

now I'm gonna play devil^Wsysadmin's advocate for a minute here ;)

> 
> Ignored disadvantages;
> * having each app in koffice as a repo and doing a refactor means you need
> to push to multiple repositories. Managing multiple repositories is not
> something that git is good at and as a result you will have to do multiple
> pushes yourself. This has a real-life effect on daily operations.

still, doing a refactor isn't a regular thing (one would hope) so I'd count 
this as a minor annoyance.
I already do separate pushes for libs/base plasma myself, because I don't have 
the whole svn tree checked out. :)

> 
> * repositories get bigger if you put multiple applications in there, no
> surprise. They will on the whole get smaller as git compression works
> better with more data. So having 10 repos of 10 apps or having 1 repo with
> 10 apps then the one with 1 repo will be smaller over the network and on
> disk.

true - until you ask, how many people want to download all 10 vs. just one or 
two of them?
*if* most people only want one repo, it'd be faster for them to only download 
that. I don't know any numbers on this, though :)

> 
> * the splitting has shown the concern that people that want to use one
> kdeedu app will no longer benefit from finding the other ones also in the
> same module. This makes helping out with development less KDE like where
> people are invited to jump in and fix stuff.  If they don't have the
> source they are less likely to do so.

well, we still have them grouped on redmine. but yes, you might have a point 
here.
otoh, when I wanted to fix rsibreak, the main barrier was finding out *where* 
it was; I wouldn't have had it on disk anyways because it was in kdeutils, and 
I hadn't needed that yet.
downloading and building it was a matter of uncommenting two lines in a config 
file and running one command (..well, and then finding out that kgpg had 
stopped it from compiling, and disabling that so the rest of utils could 
build...)

I'm not sure if the social benefit of having a full module pre-downloaded is 
as big as people make it out to be.

If one was offline, it would certainly make a difference. It does help in 
noticing compile failures (although in the gpg case, it was some sort of cmake 
error I didn't understand, and really wasn't interested in debugging). It's 
not a particularly large burden, unless your hard drive is ridiculously small 
(and even my n900 has something like 25GB).
I suppose having others run trunk also encourages the developers to not break 
it too badly.

otoh, I've occasionally been burned by accidentally updating all of kdebase 
when really I just wanted to update plasma and not risk breaking anything else 
(it's always when you really don't have time to deal with it that someone 
manages to break the build :P)

hmm.

> 
> * we have rules for non-split repos. They work mostly. The proposal means
> we have to start over.
> 
> * rule writing for splitting individual apps is a *lot* harder than writing
> per module. So I expect this change at this time to cause a minimum delay
> of 6 months.

is it really that bad?

> 
> * I am discouraged that this one mail caused a lot of people to change
> their minds and just change direction. Which effectively means 2 years of
> consensus building and rule writing is thrown away. I don't think I can
> stumach this restart of effort and still help out with the conversion.

people changed their minds already? who? I'm still trying to gather enough 
information to make an informed decision...

the sysadmins wanted to bring new evidence for us to consider. I figured it 
was worth listening to what they had to say. I would have liked more detail 
from them, but oh well, let's work with it and get this properly documented if 
nothing else.