You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@subversion.apache.org by "Echlin, Jamie" <ja...@credit-suisse.com> on 2010/11/23 10:27:22 UTC

Should svn allow a merge into a conflicted file?

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

__SCRIPT__

@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
popd
popd


=============================================================================== 
Please access the attached hyperlink for an important electronic communications disclaimer: 
http://www.credit-suisse.com/legal/en/disclaimer_email_ib.html 
=============================================================================== 

Re: Should svn allow a merge into a conflicted file?

Posted by JamieEchlin <ja...@credit-suisse.com>.
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
registering.
cheers, jamie


JamieEchlin wrote:
> 
> 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
> 
> __SCRIPT__
> 
> @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
> popd
> popd
> 
> 
> =============================================================================== 
> Please access the attached hyperlink for an important electronic
> communications disclaimer: 
> http://www.credit-suisse.com/legal/en/disclaimer_email_ib.html 
> =============================================================================== 
> 
> 
> 

-- 
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.