> Stephan Kulow wrote:
> >I don't like a cluttered trunk - sorting apps into modules is already
> >artificial enough. We could discuss moving kdeplayground-admin into
> >kdeplayground/kdeadmin - but even that I don't really like. We have
> >77 modules so far in svn.kde.org, that's quite a lot but still easy to
> >overview. Easier than wondering if qt-copy is KDE/ or misc/ when
> >browsing.

IMHO, a bit of classification is very useful, especially for the modules that 
follow the release cycle. In general lines, I agree with Thiago's proposal in 
the howto.

El Jueves, 31 de Marzo de 2005 17:25, Thiago Macieira escribió:
> True, but I proposed this for another reason: branching.
>
> When an app is released (say, amarok), the operations are:
> svn cp trunk/kdeextragear/amarok branches/maintenance/amarok/1.3
> svn cp trunk/kdeextragear/amarok tags/amarok/1.3.0
>
> However, when KDE is released, we would have either:
> svn cp trunk/KDE branches/maintenance/KDE/4.0
> svn cp trunk/KDE tags/KDE/4.0.0
>
> OR
>
> svn mkdir branches/maintenance/KDE/4.0
> svn mkdir tags/KDE/4.0.0
> for module in kdesupport kdelibs kdebase [...]; do
>   svn cp trunk/$module branches/maintenance/KDE/4.0/
>   svn cp trunk/$module tags/KDE/4.0
> done

I like much more the first. This is friendly not also for tagging and 
branching the official modules, but also for translators or users that try 
the new releases of KDE before they appear.

For example, a translator can checkout trunk/kde, and compile it when the 
first alpha or beta of 3.5 appears, and test how the translations look. Then 
the stable branch is created, so he can svn swith to /branch easily.

For tags and branches, I like the same layout, or one as similar as possible 
to /trunk. Another idea is having /branches for the official and/or stable 
ones, and /people for a space where experimental branches can be located.

-- 
Alex (a.k.a. suy) - GPG ID 0x0B8B0BC2
http://darkshines.net/ - Jabber ID: suy@bulmalug.net