Trying this for a third time...ccing some svn book folks if
it doesn't
get through again.
---------- Forwarded message ----------
From: Paul Burba <ptburba gmail.com>
Date: Wed, Mar 19, 2008 at 11:25 AM
Subject: Some More Chapter 4 Review
To: svnbook-dev 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-90ABEbeta
>svn ci -m "" merge_tests-90
Sending merge_tests-90ABEbeta
Transmitting file data .
Committed revision 7.
>echo conflictor! > merge_tests-90A_COPYBEbeta
>svn ci -m "" merge_tests-90
Sending merge_tests-90A_COPYBEbeta
Transmitting file data .
Committed revision 8.
>svn merge %url%/A merge_tests-90A_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-90A_COPY':
C merge_tests-90A_COPYBEbeta
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-90A_COPY':
C merge_tests-90A_COPYBEbeta
>svn pl -vR merge_tests-90
Properties on 'merge_tests-90A_COPY':
svn:mergeinfo : /A:5,7
>svn diff merge_tests-90
Property changes on: merge_tests-90A_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
_______________________________________________
svnbook-dev mailing list
svnbook-dev red-bean.com
http://www.red-bean.com/mailman/listinfo/svnbook-dev
|