[Kde-scm-interest] Meeting minutes

[Oswald Buddenhagen]

On Thu, Nov 12, 2009 at 07:05:25PM +0100, Boudewijn Rempt wrote:
> -> write a script to clone, update and build everything, like kde-svn 
>    (TASK: Morice).=
>
why *like*?

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

according to the git-svn author, if the single projects are imported
with --minimize-url, one should get fairly good history preservation
despite the extensive moving in svn. haven't tried myself yet, though.
of course, doing tens of small imports would take forever when not done
directly on the svn server (or a clone thereof).

>  ** pre/post commit hooks, write & coordinate with gitorious
>    *** post:
>      -> figure out which hooks we have right now (from 
>         http://websvn.kde.org/trunk/kde-common/svn/hooks/)
>              * CIA
>              * BUG
>              * CCMAIL 
>              * LICENSE
>              * EBN (Dario Freddi)
>              * etc.
>      -> check whether the list complete (boud, morice)
>      -> coordinate with harald sitter on writing them (morice)
>      -> get them to work with gitorious for all kde modules, they will run
>         on a kde server (morice, johan, dario)
>
i'm currently working on a completely new post-receive hook script which
is predominantly commit oriented (instead of ref update oriented like
the one from git contrib/). it will be fairly easy to get evaluation of
our magic keywords into it.
i hope to get that done this weekend. i'm half-done, i'd say.