On Mon, Apr 04, 2011 at 10:37:04AM -0500, Hyrum K Wright wrote:
> On Mon, Apr 4, 2011 at 4:56 AM, <danielsh_at_apache.org> 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
Received on 2011-04-04 19:39:27 CEST