Subversion repository structure (was: trunk/kdeedu/klettres)

mETz mETz81 at web.de
Sun Feb 20 11:55:51 GMT 2005


On Sonntag Februar 20 2005 11:53, Stephan Kulow wrote:
> Am Samstag 19 Februar 2005 22:05 schrieb Thiago Macieira:
> > The important thing here is that each tarball-to-be-released has a
> > directory of its own -- regardless where it actually is -- and is
> > compilable. That is, kdelibs is released as kdelibs-4.0.0.tar.gz,
> > so /trunk/KDE/kdelibs is compilable; amarok-1.3.0.tar.gz is released,
> > then /trunk/extragears/amarok is compilable, as is /branches/amarok/1.3.0
> > and so forth.
>
> I don't get why you want to move away from the logical groups to be
> "more svn friendly".

What is so logical about kdeextragear-[1-6326]? AFAIK the only reason we have 
these is to keep the number of admin-dirs and configure-runs lower for people 
who compile everything all the time. I don't think that group is a majority 
(most devels only work on one or two apps in a extragear, same goes for 
app-usage for bleeding-edge users).

> It might be more friendly to subversion, but it surely 
> is less friendly to _me_ - I would have to checkout tons more paths to do
> a KDE+extragear compilation. And even though the next build system

There's scripts to do that, no reason to create unneeded dirs like 
"kdeextragear" :)

> might not require admin/ I doubt k3b and amarok will use it too soon - as
> it will be KDE4 material.

What about a transition-state: Have kdeextragear dirs in svn and move apps out 
of there as soon as they switch build systems. After all that task should be 
easy to do with svn.

Bye, Stefan aka mETz




More information about the kde-core-devel mailing list