I will announce this NOW in another thread!
Oliver
Wallmer, Martin wrote:
Hi Oliver,
yes, everybody who checks in the RELEASE branch should be responsible to do this for HEAD as well. However, we need a definite time when to start with this.
Regards, Martin
-----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]
.
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
