[Kde-scm-interest] Meeting minutes

[Simon Hausmann]

On Thursday 12 November 2009 ext Oswald Buddenhagen, wrote:
> > -> every module in KDE gets a repo, every project in support/extragear
> >    gets a repo, koffice gets a repo
> > -> subprojects, like games or edu might choose to have a repo per app,
> >    however, they will have to help out then. Otherwise, they get lumped
> >    together. Will have to ask the module maintainers (TASK: Chani will do
> >    the asking)
> > -> if a subproject wants to separate all their apps, someone will have to
> >     help them (TASK)
> 
> i still think (more than ever) that doing big modules is just plain
> wrong. i'm still not convinced by a single kdelibs, but even considering
> to allow lumping codebase-wise completely unrelated applications into
> common repositories is insane.
> 
> disadvantages of big repos:
> - huge clones for everybody
> - loss of history. there are only two clean ways to preserve history
>   when moving around applications: have everything in one repo (like in
>   svn, but that just plain does not work with git) or have no need for
>   moving at all, i.e., have idependent atomic applications and do moves at
>   an abstract level (possibily via submodules).
> - merging mess (random conflict resolution). forward-merging stable =>
>   master is hard enough in qt already, and that's a well-organized
>   (kinda ;) company of full-time workers and "only" two major time zones.
>   imagine the bottlenecks in a disorganized bunch like kde. it simply
>   won't work.
> 
> advantages of big repos:
> - it's simpler to check out all at once. wow. i'm impressed.

I agree with Oswald here.

Git scales well with repositories, it does not scale well with the number or 
files inside a repository. That applies to the performance as well as the 
merging woes that you get.

Speaking from experience: We did that mistake with Qt. We did not take the 
time to split up Qt when we switched to git, and now we have one big 
repository that contains lots of unrelated code. When merging between 
difference maintenance and development branches we frequently have to resolve 
other people's merge conflicts. Sometimes the owners of the code are not 
reachable and then we either have to figure it out ourselves (error prone!) or 
we have to delay the merge, which is bad.

In addition with Qt the use of git is slow on non-Linux platforms.

We do plan to split up Qt into separate modules. If you look around how other 
projects converted to Git or Mercurial then you can observe the same pattern.

Therefore I recommend one repository per application, in some cases 
application + library (say konqueror + libkonq in one repository).


Simon
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: This is a digitally signed message part.
Url : http://mail.kde.org/pipermail/kde-scm-interest/attachments/20091116/d189eb40/attachment.sig