Hi - I hate to bump this just for the sake of it, but AFAIK an email wasn't
sent to the list from this post, maybe because I sent it immediately after
> Should Subversion allow a merge on top of a file that already contains
> an unresolved conflict? Run the script below to set up the scenario.
> The first merge introduces a conflict, the second merge contains
> incoming changes to the conflicting section. The second merge is applied
> successfully to the working copy. However, as the working copy is still
> in conflict, when you come to resolve it, the contributors overwrite the
> later changes. In the example, the contributors are foo.c.working,
> foo.c.merge-right.r4 and foo.c.merge-left.r3. When the merge is
> completed the foo.c that had contained the changes from the second merge
> are overwritten.
> I think it's a misfeature that svn allows a merge into a file that
> already contains conflicts, especially given that multiple pass merges
> are broken up for entirely the reason that there is no reliable way to
> merge a change into a file that already contains conflicts.
> It may seem unlikely that someone would do a second merge when there is
> already conflicts, however this is the case when you pick two separate
> source revisions to merge in Tortoise, and then choose to postone
> resolving all conflicts - you may not realise there is a conflict in the
> first revision as subsequent revisions may be merged successfully.
> Apparently it is documented that you must resolve interactively when
> cherrypicking, however I can't find this. Nevertheless, imho the
> behaviour in this scenario should be the same as when merging a
> non-contiguous range of revisions, ie you are forced to resolve
> conflicts after each sub-range.
> Grateful for any opinions on this... and if this is a reported bug,
> what's the ID please.
> cheers, jamie
> @rem config
> SET REPO_PATH=file:///c:/tmp/TestMergeIssue/repo
> rm -rf wc repo
> svnadmin create repo
> svn co %REPO_PATH% wc
> pushd wc
> mkdir trunk branches
> echo 1 >> trunk\foo.c
> echo 2 >> trunk\foo.c
> echo 3 >> trunk\foo.c
> echo 4 >> trunk\foo.c
> echo 5 >> trunk\foo.c
> echo 6 >> trunk\foo.c
> echo 7 >> trunk\foo.c
> echo 8 >> trunk\foo.c
> echo 9 >> trunk\foo.c
> svn add trunk branches
> svn commit -m "1"
> svn cp trunk branches/1.0
> svn commit -m "2"
> @rem change 2nd line on trunk
> perl -pi.bak -e "s/2/B trunk/" trunk/foo.c
> svn commit -m "3" trunk/foo.c
> @rem add lines on branch
> perl -pi.bak -e "s/2/A.ny\nB.ny\nC.ny\nD.ny/" branches/1.0/foo.c
> svn commit -m "4" branches/1.0/foo.c
> @rem this will conflict now
> @rem modify two of the lines on branch
> perl -pi.bak -e "s/C.ny/C/" branches/1.0/foo.c
> perl -pi.bak -e "s/D.ny/D/" branches/1.0/foo.c
> svn commit -m "5" branches/1.0/foo.c
> pushd trunk
> svn merge --accept postpone -c 4 ^^/branches/1.0
> svn merge --accept postpone -c 5 ^^/branches/1.0
> Please access the attached hyperlink for an important electronic
> communications disclaimer:
View this message in context: http://old.nabble.com/Should-svn-allow-a-merge-into-a-conflicted-file--tp30286560p30296054.html
Sent from the Subversion Users mailing list archive at Nabble.com.
Received on 2010-11-24 12:46:31 CET