|
| Re: Aggregator debate - take 2 [message #600226 is a reply to message #600209] |
Sat, 27 February 2010 10:15   |
 Filip Hrbek
Messages: 233
Registered: July 2009 |
Senior Member |
|
|
This was almost possible in my experimental implementation. I must say "almost" because the whole repository R1 was available
to the final process for resolving dependencies. I guaranteed that the user got what explicitly selected, but
he could not control where the dependencies come from.
Example:
Repo A contains:
a.b.c/1.0.0 which depends on x.y.z/[1.0.0,1.5.0]
x.y.z/1.1.0
Repo B contains:
d.e.f/1.0.0 which depends on x.y.z/[1.0.0,1.5.0]
x.y.z/1.4.0
a.b.c/1.1.0.beta which depends on x.y.z/[1.0.0,1.5.0]
User A (in contribution A) requires
a.b.c/[1.0.0,MAX] defined under Repo A (he can see that the repo contains only 1.0.0, I think he expect this to be chosen)
User B (in contribution B) requires
d.e.f/[1.0.0,MAX] defined under Repo B (he can see that the repo contains only 1.0.0, I think he expect this to be chosen)
Algorithm 1)
The result of the aggregation AS IT STANDS TODAY is:
a.b.c/1.1.0.beta from B - since it is the best match for A's request for a.b.c/[1.0.0,MAX]
d.e.f/1.0.0 from A - since it the best match of B's request for d.e.f/[1.0.0,MAX]
x.y.z/1.4.0 from B - since it is the best match for both a.b.c's and d.e.f's dependency request
I think that user A may be surprised where a.b.c/1.1.0.beta comes from.
Algorithm 2)
The result of the aggregation AS IT WORKED IN MY EXPERIMENT is:
a.b.c/1.1.0 from A - since it is the best match for A's request for a.b.c/[1.0.0,MAX] from the repository where user A defined his request
d.e.f/1.0.0 from A - since it the best match of B's request for d.e.f/[1.0.0,MAX] from the repository where user B defined his request
x.y.z/1.4.0 from B - since it is the best match for both a.b.c's and d.e.f's dependency request, the scope for searching the dependencies is not limited
I think that with current model it should work like alg. 2).
If we say that alg. 1) is correct (I don't say it is incorrect!), then we should change the model and the UI.
In my view, both are correct! But then, we should change the model, the UI and add options to specify explicitly the scope of resolution. One of the algorithms becomes the default.
I would prefer to have a beer, a big table (not talking about software but real wooden table), a pen and a sheet of paper... and find the best solution :-)
Filip
Henrik Lindberg wrote:
> Hi,
> been thinking about this and wonder if the use case under debate is
> achieved by the following:
>
> - Repository R1 is mirrored to R2 and configured to only mirror
> component A (and what it requires).
> - In a second aggregation I use repository R2 and aggregate this with a
> bunch of other repositories.
>
> This way, my end result includes only the items I really wanted to get
> from R1.
>
> Will this handle the case Achim brought up?
>
> If so, how can the above be supported using only one aggregation?
> The extra repository creation step seems unnecessary to enable "cherry
> picking" - a use case that I think is not too uncommon.
>
> Regards
> - henrik
|
|
|
| Re: Aggregator debate - take 2 [message #600238 is a reply to message #600209] |
Sat, 27 February 2010 10:36 |
|
On 02/27/2010 01:58 AM, Henrik Lindberg wrote:
> Hi,
> been thinking about this and wonder if the use case under debate is
> achieved by the following:
>
> - Repository R1 is mirrored to R2 and configured to only mirror
> component A (and what it requires).
> - In a second aggregation I use repository R2 and aggregate this with a
> bunch of other repositories.
>
> This way, my end result includes only the items I really wanted to get
> from R1.
>
> Will this handle the case Achim brought up?
>
That case is already handled since the planner prevents results that are inconsistent.
> If so, how can the above be supported using only one aggregation?
You use a version range that is restrictive enough to give you the A that you want.
> The extra repository creation step seems unnecessary to enable "cherry
> picking" - a use case that I think is not too uncommon.
>
Using id + versionRange should give you all the cherry picking capabilities you need. That's of course unless you think
that the same IU found in different repositories really are different IU's (a view that in itself opens up a whole new
can of worms).
- thomas
|
|
|
Powered by
FUDForum. Page generated in 0.03196 seconds
] 
Search
Help
Register
Login
Home
