felix-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stuart McCulloch <mccu...@gmail.com>
Subject Re: Less restrictive conflict resolution for fragment imports
Date Thu, 17 Dec 2009 13:27:58 GMT
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
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

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

> 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 :)

> -Guo

Cheers, Stuart

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message