[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-core-devel
Subject:    Re: SVN timing
From:       Stephan Kulow <coolo () kde ! org>
Date:       2005-03-31 13:36:40
Message-ID: 200503311536.41454.coolo () kde ! org
[Download RAW message or body]

Am Mittwoch 23 März 2005 12:42 schrieb Thiago Macieira:
> 1) /trunk/kdelibs vs /trunk/KDE/kdelibs
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.

> 
> 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.
But so far this whole layout discussion is between you and me. No-one else seems
to have an oppinion about it ;(

> 
> 3) admin with svn:external vs admin with symlinks
symlinks are the only real solution as long as relative properties do not work (and
I guess they would require a newer client version). Of course they have plenty of
disadvantages but also quite some advantages.

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.

Greetings, Stephan
[prev in list] [next in list] [prev in thread] [next in thread]