Am Samstag, 2. Juni 2012, 10:56:17 schrieb Sebastian Dörner: > On 2 June 2012 07:36, Friedrich W. H. Kossebau <kosse...@kde.org> wrote: > > Am Freitag, 1. Juni 2012, 15:39:37 schrieb Jeremy Whiting: > >> On Fri, Jun 1, 2012 at 3:36 PM, Josef Weidendorfer > >> > >> <josef.weidendor...@gmx.de> wrote: > >> > Am 01.06.2012 17:19, schrieb Friedrich W. H. Kossebau: > >> >> I just wrote in the parallel email that I would vote for following > >> >> Jeremy's > >> >> > >> >> proposal: > >> >>>>> The > >> >>>>> moving from top level to under the application can be done with > >> >>>>> svn2git rules though (and needs to be done for older branches/tags > >> >>>>> anyway), so I suggest we leave them in place in svn and move them > >> >>>>> as > >> >>>>> part of the migration to git. I'll try to spend a bit of time this > >> >>>>> weekend remembering how that is done and doing the same for the > >> >>>>> kdesdk/doc folder in the rules. > >> > > >> > Yes, this is the right thing. > >> > > >> > However, no action needed: it is already taken care of in the common > >> > kdesdk rules, and seems to work well. > >> > > >> > Josef > >> > >> Ah, excellent. I was looking forward to running the rules tomorrow. > >> Maybe I'll do that anyway, just for kicks. > > > > If you do so, can you see what can be done for doc/kmtrace? > > Because kmtrace was going to be moved to utils/kmtrace, and thus > > doc/kmtrace should ideally go to utils/doc/kmtrace. Well, would also need > > a new utils/doc and utils/doc/CMakeLists.txt, so better simply goes to > > utils/doc, can be changed after the migration for master then to be in > > another subdir utils/doc/kmtrace. > > > > Before I was going to commit the new utils/ right this morning, that > > doc/kmtrace always slipped my eyes :/ > > > > Hm, this utils/ thingie really complicates things. If I move the stuff in > > trunk now, than the rules which need to move the stuff automatically for > > the branches get more complicated, or? Asked about that on > > kde-scm-interest. > This is correct. Basically you have two options: > a) make rules a bit more complicated > b) have a broken build for the newly created repo (due to missing > top-level CMakeLists.txt) > > I think it doesn't make much of a difference, but tend to prefer option b).
So would I. So far I expect a little cleanup needed after the migration anyway, so any other related work could be done then as well. As long as the effective migration is done with enough time before to the next tagging, there should be no big problem. Should be effectively less work to do in the end. And for old, unmaintained branches the split-up in several repos results in a broken build-setup anyway, as can be seen with the previous migrations, so that by-effect seems officially accepted ;) Cheers Friedrich _______________________________________________ kde-sdk-devel mailing list kde-sdk-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-sdk-devel
