[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: mergeinfo assertion in trunk Re: 'svn switch' now requires --ignore-ancestry?

From: Paul Burba <ptburba_at_gmail.com>
Date: Mon, 25 Apr 2011 14:55:02 -0400

On Mon, Apr 25, 2011 at 11:56 AM, Paul Burba <ptburba_at_gmail.com> wrote:
> On Sat, Apr 23, 2011 at 5:21 AM, Daniel Shahaf <d.s_at_daniel.shahaf.name> wrote:
>> On Sat, 23 Apr 2011 07:15 +1000, "Daniel Becroft" <djcbecroft_at_gmail.com> wrote:
>>> Hi,
>>>
>>> I've just updated to trunk_at_1096029, and have noticed the following change in
>>> behavior.
>>>
>>> Previously, any reproduction script I write has the following pattern:
>>>
>>> svn checkout <url> workingcopy
>>> > pushd workingcopy
>>> > svn mkdir trunk
>>> > svn commit
>>> > svn switch <url>/trunk .
>>> >
>>>
>>> This used to work fine. But now I'm getting the following error messages:
>>>
>>> subversion/svn/switch-cmd.c:184: (apr_err=195012)
>>> > svn: E195012: Path '.' does not share common version control ancestry with
>>> > the requested switch location.  Use --ignore-ancestry to disable this check.
>>> > subversion/libsvn_client/switch.c:201: (apr_err=195012)
>>> > svn: E195012: 'file:///home/djcbecroft/dev/sandpit/repository/trunk' shares
>>> > no common ancestry with '/home/djcbecroft/dev/sandpit/workingcopy'
>>> >
>>>
>>> As the error message suggests, using --ignore-ancestry works fine. I don't
>>> think this is required, though, as the paths share a common ancestry
>>> already.
>>>
>>
>> I've not read the whole thread, but tweaking your recipe I've just run into an assertion in a case I expected to work:
>>
>> [[[
>> % 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_at_1 and ^/@0.  svn_client__get_youngest_common_ancestor()
> uses svn_client__get_history_as_mergeinfo() to convert ^/trunk_at_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.

Paul
Received on 2011-04-25 20:55:30 CEST

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.