From kde-core-devel Thu Mar 31 15:25:08 2005 From: Thiago Macieira Date: Thu, 31 Mar 2005 15:25:08 +0000 To: kde-core-devel Subject: Re: SVN timing Message-Id: <200503311225.10690.thiago () kde ! org> X-MARC-Message: https://marc.info/?l=kde-core-devel&m=111228273126825 MIME-Version: 1 Content-Type: multipart/mixed; boundary="--nextPart3482540.7XTfIfe0a1" --nextPart3482540.7XTfIfe0a1 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline 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).=20 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=20 see /branches/KDE, /branches/k3b, /branches/amarok, etc., which make it=20 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=20 revision number for your last branch/merge, or you can use svnmerge. So=20 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=20 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=20 option for them. However, I am afraid that people are just unaware of the=20 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=20 based on to adapt the new commit-email.pl script, as well as the ACL one.=20 I don't see why we should ignore it. So, import and delete. =46inally: 6) /tags vs /releases I prefer the latter, especially considering the "no work tags" I explained= =20 above. However, one might argue we can have tags that aren't official=20 releases. =2D-=20 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=C3=A6s n=C3=A1ht, se scieppend =C3=BEone = circolwyrde=20 wundorcr=C3=A6ftl=C3=ADge cennede and seo eor=C3=B0e w=C3=A6s idel and hit = w=C3=A6s g=C3=B3d. --nextPart3482540.7XTfIfe0a1 Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.0 (GNU/Linux) iD8DBQBCTBZWM/XwBW70U1gRAr2VAJ9qGsSa2yMTiJuxTm/Xq1trbQPuVQCgnEaN 4vX4v4b29XTPLHdtDJAoh88= =D/sn -----END PGP SIGNATURE----- --nextPart3482540.7XTfIfe0a1--