On Mon, Apr 04, 2011 at 10:37:04AM -0500, Hyrum K Wright wrote: > On Mon, Apr 4, 2011 at 4:56 AM, <[email protected]> wrote: > > Author: danielsh > > Date: Mon Apr 4 09:56:58 2011 > > New Revision: 1088533 > > > > URL: http://svn.apache.org/viewvc?rev=1088533&view=rev > > Log: > > Resolve issue #3469 (tree conflict under a directory external). > > Does this mean the issue can be closed?
Depends. There is still a can of worms here. In 1.6.x, we flag a tree conflict on the external, and this triggered a bug leading to the assertion failure described in the issue. The reproduction script for this assertion failure showed a different bug in 1.7.x. This bug ended up being tracked by the same issue. In 1.7.x, we now skip files a merge wants to add to an external. I think this is OK since it doesn't make much sense for a merge to touch multiple working copies. We don't record mergeinfo on externals either if the merge was started in the parent working copy. However, if we cherry-pick a file modification to a non-existent file within the external, we still get a tree conflict flagged within the external (try the issue-3469.sh script from the issue with the small tweak below). Merges should either always skip externals and never flag any conflicts in them, or should consistently flag conflicts. I think we should open a new issue with milestone 1.7-consider (since this is an edge case) and close #3469 with milestone 1.6.x, As an aside, the conflict description generated in 1.6.x doesn't make much sense. It says "local delete, incoming edit upon merge". But that's another issue. I'm not even sure what the description should say. --- issue-3469.sh.orig Mon Apr 4 19:26:42 2011 +++ issue-3469.sh Mon Apr 4 19:22:26 2011 @@ -50,6 +50,9 @@ svn add $scratch/test/file.txt svn ci $scratch -m "add a file" +echo test >> $scratch/test/file.txt +svn ci $scratch -m "change file" + rev=`svnlook youngest $repos` svn merge -c $rev $scratch_url $ext
