SVN timing

[Thiago Macieira]

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.

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

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 
no /branches/maintenance.

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

Finally:
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 
releases.

-- 
  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
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://mail.kde.org/pipermail/kde-core-devel/attachments/20050331/dd425de7/attachment.sig>