Good morning Paul, Paul Burba wrote on Mon, Apr 25, 2011 at 14:55:02 -0400: > On Mon, Apr 25, 2011 at 11:56 AM, Paul Burba <ptbu...@gmail.com> wrote: > > On Sat, Apr 23, 2011 at 5:21 AM, Daniel Shahaf <d...@daniel.shahaf.name> > > wrote: > >> On Sat, 23 Apr 2011 07:15 +1000, "Daniel Becroft" <djcbecr...@gmail.com> > >> wrote: > >> [[[ > >> % rm -rf wc1 r1 > >> % $svnadmin create r1 > >> % $svn co file://$PWD/r1 wc1 > >> Checked out revision 0. > >> % cd wc1 > >> % $svn cp . trunk > >> svn: E200007: Cannot copy path '/tmp/svn/wc1' into its own child > >> '/tmp/svn/wc1/trunk' > >> % $svn cp ^/ ^/trunk -mm > > > > Hi Daniel, > > > > Should we even allow a copy of r0? What exactly does it mean and how > > is it useful? > > > > The assert you see here happens because mergeinfo has no concept of r0 > > as a valid change. When we try this switch without using > > --ignore-ancestry, switch.c:switch_internal() calls > > svn_client__get_youngest_common_ancestor looking for common ancestor > > of ^/trunk@1 and ^/@0. svn_client__get_youngest_common_ancestor() > > uses svn_client__get_history_as_mergeinfo() to convert ^/trunk@1 and > > /^@0 to svn_mergeinfo_t. > > > > Unfortunately svn_client__get_history_as_mergeinfo() does this > > conversion by using svn_mergeinfo__mergeinfo_from_segments() to covert > > svn_location_segment_t's into mergeinfo. > > svn_location_segment_t.range_start can be the same as > > svn_location_segment_t.range_end, but when > > svn_mergeinfo__mergeinfo_from_segments converts these to > > svn_merge_range_t, it enforces the rule that svn_merge_range_t.start < > > svn_merge_range_t.end (see > > http://svn.apache.org/viewvc?view=revision&revision=924201). > > > > So we end up with a bogus rangelist that later trips the assert when > > svn_client__get_youngest_common_ancestor() sends it to the > > svn_rangelist_intersect API. > > > > Unsure how to address this. We could tweak > > svn_client__get_youngest_common_ancestor() to handle this edge case, > > but I wonder if preventing copies of r0 in the first place is > > something to consider too. > > We allowed this in 1.6, so I made a few changes in r1096561 and > r1906562 to continue supporting it. >
Thanks for the detailed explanation. I agree that copying r0 should be allowed. > Paul Daniel