[SvnBook] #104: ch04: Review of chapter 4 - Branching of Merging
SvnBook
noreply at red-bean.com
Mon Mar 31 23:12:03 CDT 2008
#104: ch04: Review of chapter 4 - Branching of Merging
-----------------------+----------------------------------------------------
Reporter: cmpilato | Owner: sussman
Type: defect | Status: new
Priority: normal | Milestone: 1.5
Component: content | Version: nightly/trunk
Resolution: | Keywords:
-----------------------+----------------------------------------------------
Comment (by cmpilato):
{{{
Date: Sat, 22 Mar 2008 10:11:32 -0400
From: "Paul Burba" <ptburba {at} gmail.com>
To: svnbook-dev at red-bean.com
Subject: Fwd: Some More Chapter 4 Review
A few other thoughts from the review of chapter 4 that Julian and I did:
1) In the Branching and Merging : Basic Merging : Mergeinfo and
Previews section:
"Of course, the best way to preview a merge operation is to just do
it! Remember, running svn merge isn't an inherently risky thing; if
you don't like the results, simply svn revert -R the changes from your
working copy and retry the command with different options. The merge
isn't final until you actually svn commit the results."
It is risky if you have local modifications, since the revert will
remove those to. A user might very well merge a problematic
revision/range that they know conflicts, resolve the conflicts, then
merge another range before committing. A small clarification pointing
this out might be helpful.
2) In the Branching and Merging : Advanced Merging : Cherrypicking
section, the warning and footnote:
"Did you notice how, in the last example, the merge invocation caused
two distinct ranges of merges to be applied? The svn merge command
applied two independent patches to your working copy in order to skip
over changeset 355, which your branch already contained. There's
nothing inherently wrong with this, except that it has the potential
to make conflict resolution more tricky. If the first range of changes
creates conflicts, you must resolve them interactively in order for
the merge process to continue and apply the second range of changes.
If you postpone a conflict from the first wave of changes, the whole
merge command will bail out with an error message.[21]"
"[21] At least, this is true in Subversion 1.5 at the time of writing.
This behavior may improve in future versions of Subversion."
I'm not sure if the current behavior has "improved", but it allows us
to postpone a conflict and get a conflict on our conflict, e.g.:
>echo newer content > merge_tests-90\A\B\E\beta
>svn ci -m "" merge_tests-90
Sending merge_tests-90\A\B\E\beta
Transmitting file data .
Committed revision 7.
>echo conflictor! > merge_tests-90\A_COPY\B\E\beta
>svn ci -m "" merge_tests-90
Sending merge_tests-90\A_COPY\B\E\beta
Transmitting file data .
Committed revision 8.
>svn merge %url%/A merge_tests-90\A_COPY -c5 -c7
Conflict discovered in 'merge_tests-90/A_COPY/B/E/beta'.
Select: (p) postpone, (df) diff-full, (e) edit,
(s) show all options: p
--- Merging r5 into 'merge_tests-90\A_COPY':
C merge_tests-90\A_COPY\B\E\beta
Conflict discovered in 'merge_tests-90/A_COPY/B/E/beta'.
Select: (p) postpone, (df) diff-full, (e) edit,
(s) show all options: p
--- Merging r7 into 'merge_tests-90\A_COPY':
C merge_tests-90\A_COPY\B\E\beta
>svn pl -vR merge_tests-90
Properties on 'merge_tests-90\A_COPY':
svn:mergeinfo : /A:5,7
>svn diff merge_tests-90
Property changes on: merge_tests-90\A_COPY
___________________________________________________________________
Added: svn:mergeinfo
Merged /A:r5,7
Index: merge_tests-90/A_COPY/B/E/beta
===================================================================
--- merge_tests-90/A_COPY/B/E/beta (revision 8)
+++ merge_tests-90/A_COPY/B/E/beta (working copy)
@@ -1 +1,8 @@
+<<<<<<< .working
+<<<<<<< .working
conflictor!
+=======
+New content>>>>>>> .merge-right.r5
+=======
+newer content
+>>>>>>> .merge-right.r7
>
3) Branching and Merging : Advanced Merging : Undoing Changes section:
If after using a reverse merge to roll-back a change, we then change
our minds *again* and want to re-apply the change with a forward merge
we need to use --ignore-ancestry. Otherwise the merge logic thinks
that the change is already present (it's in the merge target's natural
history after all) and doesn't attempt the merge, thinking it is a
repeated merge attempt. This is ultimately attributable to the fact
that mergeinfo doesn't currently have a way of recording reversed
merges. Maybe you want to make a note of this?
4) Branching and Merging : Advanced Merging : Merge-Sensitive Logs and
Annotations section:
This boxed example needs a minor update:
$ svn log -v -r 390 -g
------------------------------------------------------------------------
r390 | user | 2002-11-22 11:01:57 -0600 (Fri, 22 Nov 2002) | 1 line
Changed paths:
M /branches/my-calc-branch/button.c
M /branches/my-calc-branch/README
Final merge of trunk changes to my-calc-branch.
------------------------------------------------------------------------
r383 | sally | 2002-11-21 03:19:00 -0600 (Thu, 21 Nov 2002) | 2 lines
Changed paths:
M /branches/my-calc-branch/button.c
Result of a merge from: r390
^^^
This language is now "Merged via: r390"
Paul
}}}
--
Ticket URL: <http://svnbook.red-bean.com/trac/ticket/104#comment:1>
SvnBook <http://svnbook.red-bean.com/>
More information about the svnbook-dev
mailing list