[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
  +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"


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