OK I think I've fixed what I hosed on the impl trunk.
TTFN,
-bd-
On Sep 29, 2005, at 7:46 AM, Bill Dudney wrote:
Hi Mathias,
Fixes that are to be part of the release should only be committed
to the branch (per email that Sean sent out earlier).
You are correct that conflicts will happen but that can be worked
around. One way is that you could revert the files on the trunk
then commit the correct version to the branch then we can merge
down to the trunk again and apply your changes that way. Also we
could apply the changes to the branch, merge, fix any conflict
issues then commit on the trunk, then subversion will know what to
do with future changes that are merged.
TTFN,
-bd-
On Sep 29, 2005, at 2:50 AM, Mathias Brökelmann wrote:
I´m a little bit confused now.
I´ve committed a patch for MYFACES-636 into the trunk. This patch
should also go into the next release. So I normally would commit this
patch into the 1.1.1 release branch too. But if someone merges
everything after r292232 from the branch into the trunk again
wouldn´t
there be a conflict since my stuff is already in both trunk and the
branch? Or have I missed a discussion about this?
2005/9/29, Bill Dudney <[EMAIL PROTECTED]>:
Hi Sean,
I was able to perform a merge from the branch to the trunk like
this;
svn merge https://svn.apache.org/repos/asf/myfaces/impl/trunk
https://svn.apache.org/repos/asf/myfaces/impl/
branches/1_1_1 .
I did this command while inside the impl subproject under 'current'.
It worked like a champ and seems to be much easier (and safer) that
what you describe below.
Thoughts?
-bd-
On Sep 28, 2005, at 1:36 PM, Sean Schofield wrote:
I merged the latest branch changes down to the trunk. If there are
more branch changes between now and Friday morning (or as a
result of
the RC testing) then I will merge them down periodically.
Here are some important notes regarding the SVN merging process and
how we have our repository set up ... (Eventually this should
make its
way into a wiki)
You need to identify the start and end point of the set of changes
that you want to merge. For the first merge you do down to the
trunk
you want to be very careful in selecting the start point. You
should
select the revision number after the last revision related to the
creation of the branch and the setup of the new svn:externals. I
accidentally selected a revision after the creation of the
branch but
then noticed there were changes to subprojects that I didn't
think had
changed. Turns out I was merging in the svn:externals which
would be
a DISASTER. We don't want the externals from the branch to EVER
be in
the trunk. Otherwise we will be working with the branch code even
though we think we are modifying the trunk.
When committing its important to mention the direction of the merge
(ie. branch to trunk) and the revisions that were merged (ie.
r292022
- r292231). This will help make sure that only the new changes are
merged down the next time. So the next merge down can be
(r292232 -
???) where ??? = the latest revision number at the moment.
sean
--
Mathias
