On Wed, Apr 1, 2009 at 10:12 AM, Adriaan de Groot <groot at kde.org> wrote: > On Saturday 28 March 2009 08:47:45 Lukas Oboril wrote: >> you was the first who is started posting into default again. I >> dont'understand why we are using 'branches' instead of 'tips'. Nobody >> knows about kde-4.1.4. Ben was commiting into default too. > > Mercurial does bring some new things into the mix, yes. And we have already > reached the conclusion that the branches in Mercurial were certainly done too > early. Pavel points out that multiple repo's is the more-standard way to do > branching than using Mercurial's actual branch capabilities. > >> Conclusion: >> We have to merge both together once again, but in this way ? kde.4.1.4 >> > default. Remove or something like that kde-4.1.4, Continue work in >> default with KDE 4.1.4 and if it will be 'done' than we can use mark a >> 'TIP' as kde-4.1.4 > > > Yes, that's what we already tried. Merge all the branches to a single head > (where you wrote 'tip' above you mean 'head' -- there's only one tip, but > there may be multiple heads when things have branched/diverged). Remove all > references to updating to a branch, then carry on on the default head (which > is the only one). As long as no one starts adding changesets with another > branch as parent, we're good then. > > Note that doing stuff in a named branch is no different from people pushing > changes without doing a hg up and rebasing their changes. You get branches > (i.e. multiple heads) in the repo, which need to be merged again. >
Ok, merge kde-4.1.4 into default and kick out kde-4.1.4 branch. I agree with that. We will have one 'default' branch, then we can use tags for marking releases. >> I would like to arrange some disccussion about SCM system, because >> from my point of view, that's not a good state.I'd like too see in >> discussion these people: Stefan, Adriaan, Ben, Luc, Mark. Topic : How >> to do things in one SCM repository as simple as possible. > > Something for a separate mail thread, I think. > > I like Mercurial - I genuinely do. But it has a learning curve that seems a > little steeper than SVN, which may make it unsuitable for a project like this > one (writing specs together towards a milestone of KDE 4.1.4). Not that > Mercurial is doing badly, though: the kind of bumps we are hitting are very > minor and generally solved with a quick merge and telling someone on the list > to hg pull -u. > I like HG too :) > But if you were to propose "Let's do specs development in Dude again, since I didn;t tell something liek this ;) I wouldn't see "the concept of two repos put in one chain". One repo with specs and with 'our' tarballs from our 'codebase' I'm sorry I'm too busy right now (my home is under big re-construction). I'd like explain my vision to you. I'll hope that weekend will be fine for that. > that gives us no branches and no multiple heads" then I'd be all for seriously > considering it (e.g. the effort needed to update the documentation, effect on > new contributors, parallel discussion on how specfiles and patch development > should work together). > > > > > -- > Adriaan de Groot - KDE Quality Team, KDE-Solaris > ? ? ? ? ? ? ? ? - http://www.englishbreakfastnetwork.org/ > ? ? ? ? ? ? ? ? - http://solaris.kde.org/ > _______________________________________________ > kde-discuss mailing list > kde-discuss at opensolaris.org > http://mail.opensolaris.org/mailman/listinfo/kde-discuss > -- Lukas 'Luc' Oboril IRC nickname: luc^ at freenode When dealing with people, let us remember we are not dealing with creatures of logic. We are dealing with creatures of emotions, creatures bristling with prejudices and motivated by pride and vanity. Dale Carnegie
