Hi Phillip.
Thanks for the response.
I am unclear about the intended functionality of SVN when using merge -c -M
(or -r M:<M-1>), given your response and the instructions in the svn book.
If I display the conflict brought up by the aforementioned merge command,
svn merge -c -4 file:///path_to_repos/trunk,
it reads as follows:
------
this is an edit of testcode.py. r2.
this is another edit of testcode.py. r3.
<<<<<<< MINE (select with 'mc') (6,6)
this is an edit of testcode.py. will get rid of this one. r4.
another edit of testcode.py. keeping it. r5.
yet another edit of testcode.py. also keeping it. r6.
||||||| ORIGINAL (6,2)
this is an edit of testcode.py. will get rid of this one. r4.
=======
>>>>>>> THEIRS (select with 'tc') (6,0)
------
There is no choice for built-in conflict resolution that delivers the
result claimed in the svn book for "Undoing Changes." That is, neither
resolved (r), mine-conflict (mc), theirs-conflict (tc), mine-full (mf), nor
theirs-full (tf) will create a file with all lines of the working copy
intact except for the one ending in r4. Therefore, I'm not sure how a
"more permissive" algorithm could be a solution. The built-in choices for
conflict resolution (barring visual inspection and editing by the user) are
1) keep the file as it was before the merge attempt,
2)revert the file to r3, or
3)revert the file to r4.
The only way to produce the claimed functionality of undoing past changes
in this simple case is to visually inspect the displayed conflict using the
dc command (it is not at all obvious how to find the differences by
postponing and inspecting the resulting files, even in the ideal simple
case I am testing), edit the working copy to produce the desired result,
and commit.
In this very simple case, that is not very difficult. In real-life
situations, it would be at best extremely burdensome, and very prone to
user error. This doesn't seem to me to be the intended, and isn't anything
like the use case described in the svn book.
If, however, this is the way SVN expects merge -c -M to be used to undo
past "bad" changes to files in a repository, then the intention is not
properly represented in the svn book. There should be a clear statement,
in that case, that the **only** case in which merge -c -M is useful is if
all changes committed in revision M were made at the end of the file or
files being committed. In real-world use cases, it would be just as easy
if not easier to svn cat or diff the files before and after the offending
commit, find the differences that way (with less clutter than appears in
with the dc command), and edit the working copy by hand to reverse the
changes.
But again, since you mentioned using a tool with a more permissive
algorithm to "allow a merge without a conflict," it sounds as though one of
the potential outcomes of the conflict raised by SVN should be a file with
line r4 having been removed. If that's not the case and everything is
functioning as designed, please let me know. I would again stress that if
that is the case, the instructions on the topic should be changed. In
fact, the whole "Undoing Changes" section of the svn book could be removed
entirely.
Thanks again for your time.
Nairn
On Mon, Jul 2, 2012 at 1:41 AM, Philip Martin <philip.martin_at_wandisco.com>wrote:
> Nairn Baliber <planetkiller_at_gmail.com> writes:
>
> > This creates a conflict (upon running that command, not on commit),
> whereby
> > the merge-left file contains everything up until line r4, and the
> > merge-right file contains everything up until line r3. In other words,
> > instead of removing a past change, the command seems to want to revert
> the
> > entire file back to either revision 3 or 4, removing changes in
> subsequent
> > revisions (5 and 6, in this case).
>
> The left and right files are simply the r3 and r4 files and the
> difference is a line added at the end of the file. The merge attempts
> to remove the line from the current file where the line is no longer at
> the end. Subversion's merge algorithm detects that the context
> following the line in the current file has no match in the original file
> and flags a conflict. A more permissive algoithm would ignore the
> conflict and allow the merge. That's a better result in some cases but
> it may well be a worse result in other cases.
>
> You can configure Subversion to use an external diff3/merge tool.
> kdiff3 has a more permissive algorithm that allows the merge without a
> conflict.
>
> --
> Philip
>
Received on 2012-07-03 01:27:37 CEST