Mailing-List: contact dev-help@felix.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@felix.apache.org
Received-SPF: pass (nike.apache.org: domain of heavy@ungoverned.org designates
 67.222.38.31 as permitted sender)
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=ungoverned.org;
	h=Received:Message-ID:Date:From:User-Agent:MIME-Version:To:Subject:References:In-Reply-To:Content-Type:Content-Transfer-Encoding:X-Identified-User;
	b=szHr5+rS04OOdt6MI+r1eNuPXjJKpwgDh34U5aPnsDnCC7dLqhc/ZpOGWnwhuxIL5yBZNUr/J9zcsOlOL/Hx8Mfyd9oWx0lMmn11veTsKvUDNzhi/vZiHHhw5AZhe9wR;
Message-ID: <4B2A4357.5090202@ungoverned.org>
Date: Thu, 17 Dec 2009 09:42:31 -0500
From: "Richard S. Hall" <heavy@ungoverned.org>
User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US;
 rv:1.9.1.5) Gecko/20091204 Thunderbird/3.0
MIME-Version: 1.0
To: dev@felix.apache.org
Subject: Re: Less restrictive conflict resolution for fragment imports
References: 
 <OFD7D5D61F.808D884D-ONC125768E.005E3282-8825768E.005ECCAB@sybase.com>
	 <4B2916C1.9030809@ungoverned.org>
	 <81f0d9c0912160937x1b040c8ej98ce3d6eb55adae4@mail.gmail.com>
	 <e2a35cbc0912170515y2a04a4aif638e51d780f88a0@mail.gmail.com>
 <81f0d9c0912170527q4fc2a250lc2478c1b56376a7f@mail.gmail.com>
In-Reply-To: <81f0d9c0912170527q4fc2a250lc2478c1b56376a7f@mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

On 12/17/09 8:27, Stuart McCulloch wrote:
> 2009/12/17 Guo Du<mrduguo@gmail.com>
>
>    
>> On Wed, Dec 16, 2009 at 5:37 PM, Stuart McCulloch<mcculls@gmail.com>
>> wrote:
>>      
>>> So +1 to trying the intersection approach.
>>>        
>> Intersection ONLY is not safe for the case:
>>      
>>> Host version [2.0.0,3.0.0)
>>> [2.5.0,2.9.0)
>>> Fails, when host is importing 2.1.0 this would cause fragment to fail.
>>>        
>>      
> depends when the intersection was made - if it was done before the host
> resolved
> then the host's import range would shrink to the intersection: [2.5.0,2.9.0)
> and the
> host plus fragment would not be in conflict.
>
> now if you're attaching the fragment to an already resolved host then I
> believe the
> resolver would look at the existing wires, not the original range - so if
> the host was
> already wired to 2.1.0 then the fragment wouldn't be able to attach
> dynamically
>
> but then this is still correct (afaik) in that you can't dynamically attach
> a fragment
> that conflicts with the resolved host (btw, do we support dynamic
> attachment?)
>    

No, we don't.

>> We may have following condition to enable fragment:
>> 1. exact version match or
>> 2. host version range inside all fragments version or
>> 3. all fragments and host share intersection + dynamic verify the
>> actual imported version is inside intersection
>> (p.s. I am not sure "dynamic verify the actual imported version is
>> inside intersection" is viable or not. If not, we could do at least
>> step 2 which will help both Andreas's and FELIX-1919 case )
>>
>>      
> these still fall under 'intersection' imho (ie. the intersection should
> apply to the
> host and fragment) but let's see what Richard's algorithm actually looks
> like :)
>    

The intersection approach will create a new version range each time a 
fragment is added and the next fragment will be compared against that 
range in bundle ID order. I don't think this will allow for any valid 
cases since we are always making the allowed version range more narror.

-> richard

>
>    
>> -Guo
>>
>>      
>