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