Fwd: Some More Chapter 4 Review

[Paul Burba]

Trying this for a third time...ccing some svn book folks if it doesn't
get through again.

---------- Forwarded message ----------
From: Paul Burba <ptburba at gmail.com>
Date: Wed, Mar 19, 2008 at 11:25 AM
Subject: Some More Chapter 4 Review
To: svnbook-dev at red-bean.com


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