thiago at kde.org
Thu Mar 31 16:25:08 BST 2005
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
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
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
Hence my suggestion of trunk/KDE: what KDE releases gets stored there
There's no big difference in either operation, since both are O(1).
There's only a difference in the effort on the release dude.
>> 2) /work/work-branch vs /branches/work/work-branch
>> vs /branches/appname/work-branch
>For branches I agree. We have 155 branches without unlabeled ones.
> That's already a lot and they are pretty hard to overview. But if you
> add /branches/appname you're not easing to find a branch. So I would
> split /branches into /branches/work and /branches/maintaince - this
> should split the list of branches enough and I can script it very
> easily to move the branches after the import.
I think /branches/maintenance is a bit overkill. I'd like to
see /branches/KDE, /branches/k3b, /branches/amarok, etc., which make it
easier to find a maintenance branch.
Not to mention the spelling problems with "maintenance" :-)
That adds a new point:
2b) /branches and /tags: same structure?
There are no "working tags" since you can easily just remember/store a
revision number for your last branch/merge, or you can use svnmerge. So
there's no point in /tags/maintenance and /tags/work.
So, will we have the same structure for /branches and /tags?
I would prefer that we did, in conjunction with what I proposed above for
>But so far this whole layout discussion is between you and me. No-one
> else seems to have an oppinion about it ;(
I would say that people are consenting that we will come to the best
option for them. However, I am afraid that people are just unaware of the
impact and aren't paying attention.
>I'd like to add:
>5) to migrate CVSROOT and delete it afterwards or ignore it? The history
> of it is part of the history of KDE's cvs so it's a bad sad, but of
> course it doesn't serve any good.
CVSROOT also contains some scripts that we have used, including what I
based on to adapt the new commit-email.pl script, as well as the ACL one.
I don't see why we should ignore it. So, import and delete.
6) /tags vs /releases
I prefer the latter, especially considering the "no work tags" I explained
above. However, one might argue we can have tags that aren't official
Thiago Macieira - thiago (AT) macieira (DOT) info
PGP/GPG: 0x6EF45358; fingerprint:
E067 918B B660 DBD1 105C 966C 33F5 F005 6EF4 5358
1. On frumscafte, hwonne time_t wæs náht, se scieppend þone circolwyrde
wundorcræftlíge cennede and seo eorðe wæs idel and hit wæs gód.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 189 bytes
Desc: not available
More information about the kde-core-devel