Author: buildbot
Date: Sat Nov 26 09:18:55 2016
New Revision: 1001664
Log:
Production update by buildbot for camel
Modified:
websites/production/camel/content/cache/main.pageCache
websites/production/camel/content/merging-commits-from-trunk-to-fixes-branch.html
Modified: websites/production/camel/content/cache/main.pageCache
==============================================================================
Binary files - no diff available.
Modified:
websites/production/camel/content/merging-commits-from-trunk-to-fixes-branch.html
==============================================================================
---
websites/production/camel/content/merging-commits-from-trunk-to-fixes-branch.html
(original)
+++
websites/production/camel/content/merging-commits-from-trunk-to-fixes-branch.html
Sat Nov 26 09:18:55 2016
@@ -84,163 +84,45 @@
<tbody>
<tr>
<td valign="top" width="100%">
-<div class="wiki-content maincontent"><p>The Camel 2.x branches are here:</p>
-<ul class="alternate"><li><a shape="rect" class="external-link"
href="https://svn.apache.org/repos/asf/camel/branches/";>https://svn.apache.org/repos/asf/camel/branches/</a></li></ul>
-
-
-<h2 id="Mergingcommitsfromtrunktofixesbranch-Whatshouldbemerged">What should
be merged</h2>
-<p>The idea is to be able to apply bug fixes and backwards compatible
improvements and new features to our Camel maintenance branches (for example
2.10.x and 2.9.x) while leaving <strong>NON</strong> backwards compatible
changes on the trunk. The idea is to give our users the best experience
possible on any supported branch as long we have 100% backward compatibility on
patch versions.</p>
-
-<h3
id="Mergingcommitsfromtrunktofixesbranch-WhatshouldbeconsideredasNOTbackwardscompatible">What
should be considered as NOT backwards compatible</h3>
-<ul class="alternate"><li>change in our public API</li><li>change in the
behavior of a component</li><li>change in a default value of a
component</li></ul>
-
-
-<h3
id="Mergingcommitsfromtrunktofixesbranch-ChangeswhichSHOULDapplytomaintenancebranches">Changes
which SHOULD apply to maintenance branches</h3>
-<ul class="alternate"><li>Bug fix which is backwards
compatible</li><li>Smaller improvement which is backwards
compatible</li><li>Small new feature which is backwards
compatible</li><li>Third party dependency updates on micro/patch versions (3rd
digit)</li></ul>
-
-
-<h3
id="Mergingcommitsfromtrunktofixesbranch-ChangeswhichMUSTNOTbeappliedtomaintenancebranches">Changes
which MUST NOT be applied to maintenance branches</h3>
-<ul class="alternate"><li>Bug fix which is <strong>NOT</strong> backwards
compatible</li><li>Improvement which is <strong>NOT</strong> backwards
compatible</li><li>New feature which is <strong>NOT</strong> backwards
compatible</li><li>Non trivial refactoring</li></ul>
-
-
-<h3
id="Mergingcommitsfromtrunktofixesbranch-ChangeswhichMAYbeappliedtomaintenancebranches">Changes
which MAY be applied to maintenance branches</h3>
-<p>For all the changes in this category we have to be especially carefully to
not break backwards compatibly. Again, the goal is to be 100% backward
compatibility on patch versions. Take extra time to review and test your
change. Even better, send a [HEADS UP] on the dev@ mailing list and ask for
assistance/review.</p>
-<ul class="alternate"><li>Non trivial improvement which is backwards
compatible</li><li>Non trivial new feature which is backwards
compatible</li><li>Third party dependency updates on major or minor versions
(1st and 2nd digit)</li><li>Trivial refactoring</li></ul>
-
-
-<h2 id="Mergingcommitsfromtrunktofixesbranch-Whoshoulddothemerge">Who should
do the merge</h2>
-<p>It is preferred that the committer who applied the change to trunk also
merge it back to the maintenance branches. He knows best whether this fix
should go into the maintenance branche(s) or not and he can also make sure the
WIKI pages are up to date. However, other people may also merge fixes back if
they require it there. In that case, those people should pay extra attention
to make sure the changes meet the above criteria.</p>
-
-<h2 id="Mergingcommitsfromtrunktofixesbranch-Howtomerge">How to merge</h2>
-<h3 id="Mergingcommitsfromtrunktofixesbranch-Usingsvnmerge.pyscript">Using
svnmerge.py script</h3>
-
-<p>I've set up <a shape="rect" class="external-link"
href="http://www.orcaware.com/svn/wiki/Svnmerge.py";
rel="nofollow">svnmerge.py</a> to track commits from the trunk to the 2.x
branches.</p>
-
-<p>Example workflow:</p>
-
-<p>1. You just committed a fix to the trunk in revision 123456 and think that
it would be back ported to Camel 2.8.x users</p>
-
-<p>2. Check out the branch</p>
-<div class="code panel pdl" style="border-width: 1px;"><div class="codeContent
panelContent pdl">
-<script class="brush: java; gutter: false; theme: Default"
type="syntaxhighlighter"><![CDATA[
-svn co https://svn.apache.org/repos/asf/camel/branches/camel-2.8.x camel-2.8.x
-]]></script>
-</div></div>
-
-<p>3. In camel-2.8.x directory, you can get a list of commits available from
the trunk</p>
-
-<div class="code panel pdl" style="border-width: 1px;"><div class="codeContent
panelContent pdl">
-<script class="brush: java; gutter: false; theme: Default"
type="syntaxhighlighter"><![CDATA[
-svnmerge.py avail
-]]></script>
-</div></div>
-
-<p>4. Merge your commit by running </p>
-<div class="code panel pdl" style="border-width: 1px;"><div class="codeContent
panelContent pdl">
-<script class="brush: java; gutter: false; theme: Default"
type="syntaxhighlighter"><![CDATA[
-svnmerge.py merge -r 123456
-]]></script>
-</div></div>
-
-<p>5. Resolve any conflicts in the merge</p>
-
-<p>6. Commit it by running </p>
-<div class="code panel pdl" style="border-width: 1px;"><div class="codeContent
panelContent pdl">
-<script class="brush: java; gutter: false; theme: Default"
type="syntaxhighlighter"><![CDATA[
-svn ci -F svnmerge-commit-message.txt
-]]></script>
-</div></div>
-
-<p>7. If you have a JIRA associated with this fix, make sure it says fix for
2.8.x.</p>
-
-
-<h4 id="Mergingcommitsfromtrunktofixesbranch-Troublewithsvnmerge.py">Trouble
with svnmerge.py</h4>
-<p>If you have trouble with the svnmerge.py file such as Claus Ibsen had, then
he attached an older svnmerge.py file, to this wiki page that works.</p>
-
-<h3 id="Mergingcommitsfromtrunktofixesbranch-UsingDoMergestool">Using DoMerges
tool</h3>
-
-<p>If you look in:</p>
-<ul class="alternate"><li><a shape="rect" class="external-link"
href="http://svn.apache.org/repos/asf/cxf/trunk/bin/";>http://svn.apache.org/repos/asf/cxf/trunk/bin/</a></li></ul>
-
-
-<p>there is a <code>DoMerges.java</code> file in there that you can compile
and run from a fixes branch checkout.<br clear="none">
-It pretty much walks you through the entire process of backporting fixes.</p>
-
-<p>It lists all the outstanding commits that haven't been reviewed, allows you
to merge commits individually, block commits, show the diffs, etc.<br
clear="none">
-For the most part, it's quite easy to walk through a bunch of commits and
merge things back with it. Takes very little time. </p>
-
-<p>To run the file do, from the directory with the branch.</p>
-<div class="code panel pdl" style="border-width: 1px;"><div class="codeContent
panelContent pdl">
-<script class="brush: java; gutter: false; theme: Default"
type="syntaxhighlighter"><![CDATA[
-java DoMerges
-]]></script>
-</div></div>
-<p>You need <code>svnmerge.py</code> to be runnable from the command line. </p>
-
-<p>There is a compiled .class of the DoMerges attached to this wiki page you
can download. However its easy to compile<br clear="none">
-the source file, as it has no other dependencies so its all plain</p>
-<div class="code panel pdl" style="border-width: 1px;"><div class="codeContent
panelContent pdl">
-<script class="brush: java; gutter: false; theme: Default"
type="syntaxhighlighter"><![CDATA[
-javac DoMerges.java
-]]></script>
-</div></div>
-
-
-<h3 id="Mergingcommitsfromtrunktofixesbranch-Usinggit">Using git</h3>
-
-<p>If you already use git-svn, you could consider using the great git merge
capabilities.</p>
-
-<p>Create a local branch from the remote tracking branch (e.g. camel-2.8.x)</p>
-<div class="code panel pdl" style="border-width: 1px;"><div class="codeContent
panelContent pdl">
-<script class="brush: java; gutter: false; theme: Default"
type="syntaxhighlighter"><![CDATA[
-git checkout -b camel-2.8.x remotes/camel-2.8.x
-]]></script>
-</div></div>
-
-<p>or switch into the existing branch</p>
-<div class="code panel pdl" style="border-width: 1px;"><div class="codeContent
panelContent pdl">
-<script class="brush: java; gutter: false; theme: Default"
type="syntaxhighlighter"><![CDATA[
-git checkout camel-2.8.x
-]]></script>
-</div></div>
-
-<p>To merge one revision (e.g. 1176050) into this branch, run</p>
-<div class="code panel pdl" style="border-width: 1px;"><div class="codeContent
panelContent pdl">
-<script class="brush: java; gutter: false; theme: Default"
type="syntaxhighlighter"><![CDATA[
-git cherry-pick 1176050
-]]></script>
-</div></div>
-
-<p>This will merge and commit the changes into your local git repository.</p>
-
-<div class="confluence-information-macro
confluence-information-macro-information"><p class="title">Combining multiple
revisions</p><span class="aui-icon aui-icon-small aui-iconfont-info
confluence-information-macro-icon"></span><div
class="confluence-information-macro-body">
-<p>If you have to combine multiple revisions into one commit, run</p>
-<div class="code panel pdl" style="border-width: 1px;"><div class="codeContent
panelContent pdl">
-<script class="brush: java; gutter: false; theme: Default"
type="syntaxhighlighter"><![CDATA[
-git cherry-pick -n <revision>
-]]></script>
-</div></div>
-<p>for each revision (the -n options prevents the commit after the merge).
Afterwards you have to run</p>
-<div class="code panel pdl" style="border-width: 1px;"><div class="codeContent
panelContent pdl">
-<script class="brush: java; gutter: false; theme: Default"
type="syntaxhighlighter"><![CDATA[
-git commit -a -m "<commit message>"
-]]></script>
-</div></div>
-<p>to commit all the changes with one commit into your local git
repository.</p></div></div>
-
-<p>Run</p>
-<div class="code panel pdl" style="border-width: 1px;"><div class="codeContent
panelContent pdl">
-<script class="brush: java; gutter: false; theme: Default"
type="syntaxhighlighter"><![CDATA[
-git svn dcommit
-]]></script>
-</div></div>
-
-<p>to push your local changes into the Apache SVN repository.</p>
-
-<p>If you have a JIRA associated with this fix, make sure it says fix for
2.8.x.</p>
-
-<div class="confluence-information-macro confluence-information-macro-tip"><p
class="title">Git Tooling</p><span class="aui-icon aui-icon-small
aui-iconfont-approve confluence-information-macro-icon"></span><div
class="confluence-information-macro-body">
-<p>There is a number of Git Graphical Tools which can be used as well for
backporting fixes. For example GitX or GitTower for Mac
users.</p></div></div></div>
+<div class="wiki-content maincontent"><p>The Camel 2.x branches are
here:</p><ul class="alternate"><li><a shape="rect" class="external-link"
href="https://svn.apache.org/repos/asf/camel/branches/";>https://svn.apache.org/repos/asf/camel/branches/</a></li></ul><h2
id="Mergingcommitsfromtrunktofixesbranch-Whatshouldbemerged">What should be
merged</h2><p>The idea is to be able to apply bug fixes and backwards
compatible improvements and new features to our Camel maintenance branches (for
example 2.10.x and 2.9.x) while leaving <strong>NON</strong> backwards
compatible changes on the trunk. The idea is to give our users the best
experience possible on any supported branch as long we have 100% backward
compatibility on patch versions.</p><h3
id="Mergingcommitsfromtrunktofixesbranch-WhatshouldbeconsideredasNOTbackwardscompatible">What
should be considered as NOT backwards compatible</h3><ul
class="alternate"><li>change in our public API</li><li>change in the behavior
of a component</li><li
>change in a default value of a component</li></ul><h3
>id="Mergingcommitsfromtrunktofixesbranch-ChangeswhichSHOULDapplytomaintenancebranches">Changes
> which SHOULD apply to maintenance branches</h3><ul class="alternate"><li>Bug
>fix which is backwards compatible</li><li>Smaller improvement which is
>backwards compatible</li><li>Small new feature which is backwards
>compatible</li><li>Third party dependency updates on micro/patch versions
>(3rd digit)</li></ul><h3
>id="Mergingcommitsfromtrunktofixesbranch-ChangeswhichMUSTNOTbeappliedtomaintenancebranches">Changes
> which MUST NOT be applied to maintenance branches</h3><ul
>class="alternate"><li>Bug fix which is <strong>NOT</strong> backwards
>compatible</li><li>Improvement which is <strong>NOT</strong> backwards
>compatible</li><li>New feature which is <strong>NOT</strong> backwards
>compatible</li><li>Non trivial refactoring</li></ul><h3
>id="Mergingcommitsfromtrunktofixesbranch-ChangeswhichMAYbeappliedtomaintenancebranches">Changes
> which MAY be
applied to maintenance branches</h3><p>For all the changes in this category
we have to be especially carefully to not break backwards compatibly. Again,
the goal is to be 100% backward compatibility on patch versions. Take extra
time to review and test your change. Even better, send a [HEADS UP] on the dev@
mailing list and ask for assistance/review.</p><ul class="alternate"><li>Non
trivial improvement which is backwards compatible</li><li>Non trivial new
feature which is backwards compatible</li><li>Third party dependency updates on
major or minor versions (1st and 2nd digit)</li><li>Trivial
refactoring</li></ul><h2
id="Mergingcommitsfromtrunktofixesbranch-Whoshoulddothemerge">Who should do the
merge</h2><p>It is preferred that the committer who applied the change to trunk
also merge it back to the maintenance branches. He knows best whether this fix
should go into the maintenance branche(s) or not and he can also make sure the
WIKI pages are up to date. However, other people may
also merge fixes back if they require it there. In that case, those people
should pay extra attention to make sure the changes meet the above
criteria.</p><h2 id="Mergingcommitsfromtrunktofixesbranch-Howtomerge">How to
merge</h2><h3
id="Mergingcommitsfromtrunktofixesbranch-Usingsvnmerge.pyscript">Using
svnmerge.py script</h3><p>I've set up <a shape="rect" class="external-link"
href="http://www.orcaware.com/svn/wiki/Svnmerge.py";
rel="nofollow">svnmerge.py</a> to track commits from the trunk to the 2.x
branches.</p><p>Example workflow:</p><p>1. You just committed a fix to the
trunk in revision 123456 and think that it would be back ported to Camel 2.8.x
users</p><p>2. Check out the branch</p><div class="code panel pdl"
style="border-width: 1px;"><div class="codeContent panelContent pdl">
+<script class="brush: java; gutter: false; theme: Default"
type="syntaxhighlighter"><![CDATA[svn co
https://svn.apache.org/repos/asf/camel/branches/camel-2.8.x camel-2.8.x
+]]></script>
+</div></div><p>3. In camel-2.8.x directory, you can get a list of commits
available from the trunk</p><div class="code panel pdl" style="border-width:
1px;"><div class="codeContent panelContent pdl">
+<script class="brush: java; gutter: false; theme: Default"
type="syntaxhighlighter"><![CDATA[svnmerge.py avail
+]]></script>
+</div></div><p>4. Merge your commit by running</p><div class="code panel pdl"
style="border-width: 1px;"><div class="codeContent panelContent pdl">
+<script class="brush: java; gutter: false; theme: Default"
type="syntaxhighlighter"><![CDATA[svnmerge.py merge -r 123456
+]]></script>
+</div></div><p>5. Resolve any conflicts in the merge</p><p>6. Commit it by
running</p><div class="code panel pdl" style="border-width: 1px;"><div
class="codeContent panelContent pdl">
+<script class="brush: java; gutter: false; theme: Default"
type="syntaxhighlighter"><![CDATA[svn ci -F svnmerge-commit-message.txt
+]]></script>
+</div></div><p>7. If you have a JIRA associated with this fix, make sure it
says fix for 2.8.x.</p><h4
id="Mergingcommitsfromtrunktofixesbranch-Troublewithsvnmerge.py">Trouble with
svnmerge.py</h4><p>If you have trouble with the svnmerge.py file such as Claus
Ibsen had, then he attached an older svnmerge.py file, to this wiki page that
works.</p><h3 id="Mergingcommitsfromtrunktofixesbranch-UsingDoMergestool">Using
DoMerges tool</h3><p>If you look in:</p><ul class="alternate"><li><a
shape="rect" class="external-link"
href="http://svn.apache.org/repos/asf/cxf/trunk/bin/";>http://svn.apache.org/repos/asf/cxf/trunk/bin/</a></li></ul><p>there
is a <code>DoMerges.java</code> file in there that you can compile and run
from a fixes branch checkout.<br clear="none"> It pretty much walks you through
the entire process of backporting fixes.</p><p>It lists all the outstanding
commits that haven't been reviewed, allows you to merge commits individually,
block commits, show the diffs, etc.<br clea
r="none"> For the most part, it's quite easy to walk through a bunch of
commits and merge things back with it. Takes very little time.</p><p>To run the
file do, from the directory with the branch.</p><div class="code panel pdl"
style="border-width: 1px;"><div class="codeContent panelContent pdl">
+<script class="brush: java; gutter: false; theme: Default"
type="syntaxhighlighter"><![CDATA[java DoMerges
+]]></script>
+</div></div><p>You need <code>svnmerge.py</code> to be runnable from the
command line.</p><p>There is a compiled .class of the DoMerges attached to this
wiki page you can download. However its easy to compile<br clear="none"> the
source file, as it has no other dependencies so its all plain</p><div
class="code panel pdl" style="border-width: 1px;"><div class="codeContent
panelContent pdl">
+<script class="brush: java; gutter: false; theme: Default"
type="syntaxhighlighter"><![CDATA[javac DoMerges.java
+]]></script>
+</div></div><h3 id="Mergingcommitsfromtrunktofixesbranch-Usinggit">Using
git</h3><p>If you already use git-svn, you could consider using the great git
merge capabilities.</p><p>Create a local branch from the remote tracking branch
(e.g. camel-2.8.x)</p><div class="code panel pdl" style="border-width:
1px;"><div class="codeContent panelContent pdl">
+<script class="brush: java; gutter: false; theme: Default"
type="syntaxhighlighter"><![CDATA[git checkout -b camel-2.8.x
remotes/camel-2.8.x
+]]></script>
+</div></div><p>or switch into the existing branch</p><div class="code panel
pdl" style="border-width: 1px;"><div class="codeContent panelContent pdl">
+<script class="brush: java; gutter: false; theme: Default"
type="syntaxhighlighter"><![CDATA[git checkout camel-2.8.x
+]]></script>
+</div></div><p>To merge one revision (e.g. 1176050) into this branch,
run</p><div class="code panel pdl" style="border-width: 1px;"><div
class="codeContent panelContent pdl">
+<script class="brush: java; gutter: false; theme: Default"
type="syntaxhighlighter"><![CDATA[git cherry-pick 1176050
+]]></script>
+</div></div><p>This will merge and commit the changes into your local git
repository.</p><div class="confluence-information-macro
confluence-information-macro-information"><p class="title">Combining multiple
revisions</p><span class="aui-icon aui-icon-small aui-iconfont-info
confluence-information-macro-icon"></span><div
class="confluence-information-macro-body"><p>If you have to combine multiple
revisions into one commit, run</p><div class="code panel pdl"
style="border-width: 1px;"><div class="codeContent panelContent pdl">
+<script class="brush: java; gutter: false; theme: Default"
type="syntaxhighlighter"><![CDATA[git cherry-pick -n <revision>
+]]></script>
+</div></div><p>for each revision (the -n options prevents the commit after the
merge). Afterwards you have to run</p><div class="code panel pdl"
style="border-width: 1px;"><div class="codeContent panelContent pdl">
+<script class="brush: java; gutter: false; theme: Default"
type="syntaxhighlighter"><![CDATA[git commit -a -m "<commit
message>"
+]]></script>
+</div></div><p>to commit all the changes with one commit into your local git
repository.</p></div></div><p>Run</p><div class="code panel pdl"
style="border-width: 1px;"><div class="codeContent panelContent pdl">
+<script class="brush: java; gutter: false; theme: Default"
type="syntaxhighlighter"><![CDATA[git svn dcommit
+]]></script>
+</div></div><p>to push your local changes into the Apache SVN
repository.</p><p>If you have a JIRA associated with this fix, make sure it
says fix for 2.8.x.</p><div class="confluence-information-macro
confluence-information-macro-tip"><p class="title">Git Tooling</p><span
class="aui-icon aui-icon-small aui-iconfont-approve
confluence-information-macro-icon"></span><div
class="confluence-information-macro-body"><p>There is a number of Git Graphical
Tools which can be used as well for backporting fixes. For example GitX or
GitTower for Mac users.</p></div></div><h3
id="Mergingcommitsfromtrunktofixesbranch-ClosinggithubPRs">Closing github
PRs</h3><p>The PRs at github is only automatic closed if the commit log has
words like closes, fixes etc. And therefore we often ask the author of the PR
to close the PR after it has been merged, or rejected. However the author may
not see the notification or he/she does not react. So the Camel team can force
close the PRs using an empty git message:
</p><div class="code panel pdl" style="border-width: 1px;"><div
class="codeContent panelContent pdl">
+<script class="brush: java; gutter: false; theme: Default"
type="syntaxhighlighter"><![CDATA[git commit --allow-empty -m "This closes
#xxxx"]]></script>
+</div></div><p>You can then include multiple PRs etc. This closes #123. This
closes #456.</p><p> </p></div>
</td>
<td valign="top">
<div class="navigation">
