felix-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Richard S. Hall" <he...@ungoverned.org>
Subject Re: Less restrictive conflict resolution for fragment imports
Date Thu, 17 Dec 2009 14:42:31 GMT
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
>>
>>      
>    

Mime
View raw message