[Kde-scm-interest] Meeting minutes

[Ian Monroe]

On Thu, Nov 12, 2009 at 1:02 PM, Oswald Buddenhagen <ossi at kde.org> wrote:
> 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).

It is possible to move an independent git repo into another. Its not
trivial, not something you want to do everyday, but it is possible.

But actually this is one of the reasons we want to keep the kde
modules whole. It becomes trivial to move stuff around within kdebase
for example.

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

Huh? Why would there be a merging problem for "unrelated" apps in the same repo?

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

Just so its clear we're not using git-svn to do the import. :)

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

Harald Sitter is also working on one to provide CCMAIL and such to
Amarok in Ruby. Not sure if you can coordinate or not.

Ian