Hi All,
branching and merging in source control is often a source of confusion
and seems daunting at first so here is an example that covers the
"Release branch" situation we are currently in.
Greg (KI7MT) has checked out the WSJT-X v1.4 branch branches/wsjtx-1.4
and made a change that needs to go into the next release candidate
wsjtx-1.4.0-rc2. At the time of writing he has committed the change to
the branch but not yet merged it into the main line (branches/wsjtx).
The change he committed was changeset 4376 so lets have a look at it by
running 'svn diff' on the branch. Note that this command is being run
from an up to date main line checkout (branches/wsjtx):
$ svn diff -c 4376 ^/branches/wsjtx-1.4
Index: about.cpp
===================================================================
--- about.cpp (revision 4375)
+++ about.cpp (revision 4376)
@@ -16,7 +16,7 @@
"© 2001-2014 by Joe Taylor, K1JT, with grateful
<br>"
"acknowledgment for contributions from AC6SL, AE4JY,
<br>"
"DJ0OT, G4KLA, G4WJS, K3WYC, KA6MAL, KA9Q, KB1ZMX,
<br>"
- "KK1D, PY2SDR, VK3ACF, VK4BDJ, W4TI, W4TV, and
W9MDB.<br>");
+ "KI7MT, KK1D, PY2SDR, VK3ACF, VK4BDJ, W4TI, W4TV, and
W9MDB.<br>");
}
CAboutDlg::~CAboutDlg()
So now to complete the change he needs to merge into the main line.
Again from a checkout of the main line which should be up to date:
$ svn merge -c 4376 ^/branches/wsjtx-1.4
--- Merging r4376 into '.':
U about.cpp
Note that this has updated the relevant files in the working directory,
no changes have been committed to the repository at this stage. This
type of merge is called a Cherrypicking merge where we have selected
only the changes in one specific changeset to merge. This is exactly
what we want in the "Release branch" scenario.
Now as time goes on and the main line diverges from the branch due to
new features getting committed, there is a chance that a merge will
cause a conflict and you will have to edit the merged files to resolve
the conflicts manually. This normally happens when the same line of a
file has changed in both branch and main line since the branch was
created. When there is a conflict svn merge writes some extra files to
your workspace that can be used by a three way merge editor to make the
conflict resolution easy to visualize and resolve. Merge conflict
resolution is exactly the same process as dealing with conflicts after
an update when someone else has committed a change while you were
working on the same file in your workspace.
Once you have resolved any conflicts just commit your changes as normal
and you are done.
Now you might say "Why bother with all this merging, why can't I just
make the changes again in the main line?". The answer is that svn keeps
a record of merges made and will not allow them to be duplicated. Why is
that important, well often some merges don't get made, unintentionally,
so having svn be able to report what has been merged and what hasn't is
a real bonus later on when you need to find out what has gone wrong when
bugfixes made in the branch haven't turned up in the main line. Also it
is easier to use the svn merge command than doing the changes over again.
73
Bill
G4WJS.
------------------------------------------------------------------------------
Meet PCI DSS 3.0 Compliance Requirements with EventLog Analyzer
Achieve PCI DSS 3.0 Compliant Status with Out-of-the-box PCI DSS Reports
Are you Audit-Ready for PCI DSS 3.0 Compliance? Download White paper
Comply to PCI DSS 3.0 Requirement 10 and 11.5 with EventLog Analyzer
http://pubads.g.doubleclick.net/gampad/clk?id=154622311&iu=/4140/ostg.clktrk
_______________________________________________
wsjt-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/wsjt-devel
