Hello, I would vote for every committer is responsible for merging her/him-self. In my experiences I agree with Ingo, that at check-in time the merge is pretty easy.
Best regards, Juergen -----Original Message----- From: Oliver Zeigermann [mailto:[EMAIL PROTECTED] Sent: Mittwoch, 11. Februar 2004 14:50 To: Slide Developers Mailing List Subject: Re: Guide: Merging / VOLUNTEER NEEDED Hi Ingo, that sounds reasonable. Additionally, my promise was to merge changes back for a few weeks only. I think a few weeks have passed ;) What do others say? Do we need merging like this? Shall everyone be responsible for merging back his changes if applicable? Oliver Ingo Brunberg wrote: > Hi Oliver, > > I always wonder why you don't let every committer be responsible for > committing changes to the 2_0 AND the HEAD branch. At least that's how > it is handled by the Httpclient folks. IMHO that doesn't require much > additional effort, because every single committer knows best what to > merge and how to merge at the time of checking in his changes. > > And the time might come, when you don't want to have merged a > particular fix to the HEAD branch, because it's not applicable there > for some reason. > > Ingo > > >>Folks! >> >>Regular merging really is a must! That's why I am looking for a >>volunteer who is willing to take over this task from me. PLEASE! I am >>really swamped with all those administation tasks and want to get back >>to coding soon ;) >> >>What follows is a small (and necessarily incomplete) guide on how to >>merge back the changes made in the release branch. >> >>Comments / Questions / Corrections to the guide are wellcome as well. >> >>Oliver >> >> >>Tutorial: How to merge the release branch back to the HEAD branch >>----------------------------------------------------------------- >> >>(1) Made a clean check out of the HEAD branch >>(1a) Make sure the checked out version compiles and works >> >>(2) Made a clean check out of the release branch >>(2a) Make sure the checked out version compiles and works >> >>(3) Tag release branch with some sort of SLIDE_RELEASE_BRANCH_MERGE_WORK >>tag - be careful if you have already used this tag before you will have >>to remove it from *all* files. This is a problem with CVS as tags are >>associated to each file and not the other way round. To reliably remove >>this tag from all files it is associated to first check it out and then >>delete it. >> >>(4) Tag HEAD branch with SLIDE_HEAD_PRE_MERGE - see the note in (3) if >>you have already used this tag before >> >>(5) In the HEAD branch do >> >>cvs -q update -j SLIDE_2_0_RELEASE_BRANCH_LAST_MERGE -j >>SLIDE_RELEASE_BRANCH_MERGE_WORK LICENSE README RELEASE-NOTES-2.0-BETA1 >>STATUS build.properties.sample docs lib src webdavclient proposals/jdk14 >> >>This only merges in changes relevant to the HEAD. It explicitely does >>not merge testsuite and proposals/wvcm as they are deleted in the >>release branch. If they were merged as well they would be deleted in the >>HEAD as well! >> >>(5a) The main build.xml will need special attention as its targets >>reflect the overall state of Slide. E.g. testsuite targets have been >>removed from the one in the release branch while others might just have >>been fixed. So you will have to selectively merge some changes in while >>others will have to be ignored. Eclipse has a very nice tools to help >>you with this... >> >>(6) Fix conflicts >>(6a) Carefully consider which added files to take over and which deleted >>files to delete in the HEAD branch as well >>(6c) Compile and test >> >>(7) Commit the HEAD branch >> >>(8) Tag HEAD branch with SLIDE_HEAD_POST_MERGE - see the note in (3) if >>you have already used this tag before >> >>(9) Tag release branch with SLIDE_2_0_RELEASE_BRANCH_LAST_MERGE - see >>the note in (3) if you have already used this tag before >> >>(10) Remove work tag SLIDE_RELEASE_BRANCH_MERGE_WORK in release branch > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > > . > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
