Monticello cross-repository confusion?

> I had a bit of an unusual state where I had an mcz in my Pharo 2.0
> package-cache and another mcz with the same name & version in another
> directory repo, squeak-package-cache. A bit like if you were hacking
> on your release process in git and had to repeatedly git reset --soft
> HEAD^ to adjust your commit.
>
> I tried to load the _new_ mcz from squeak-package-cache, but Pharo
> insisted that that mcz was the mcz in package-cache. I only resolved
> the issue when I _deleted_ the mcz from package-cache.
>
> Has anyone else seen this before? It's frustrating and wrong: I think
> that the browser got confused because the two mczs were "the same" by
> virtue of having the same package-initials.version name. I say "wrong"
> because when viewing the squeak-package-cache repository I should see
> only those versions - regardless of name - that are in that
> repository.

>
> On 2013-03-14, at 22:59, Frank Shearar <[hidden email]> wrote:
>
>> I had a bit of an unusual state where I had an mcz in my Pharo 2.0
>> package-cache and another mcz with the same name & version in another
>> directory repo, squeak-package-cache. A bit like if you were hacking
>> on your release process in git and had to repeatedly git reset --soft
>> HEAD^ to adjust your commit.
>>
>> I tried to load the _new_ mcz from squeak-package-cache, but Pharo
>> insisted that that mcz was the mcz in package-cache. I only resolved
>> the issue when I _deleted_ the mcz from package-cache.
>>
>> Has anyone else seen this before? It's frustrating and wrong: I think
>> that the browser got confused because the two mczs were "the same" by
>> virtue of having the same package-initials.version name. I say "wrong"
>> because when viewing the squeak-package-cache repository I should see
>> only those versions - regardless of name - that are in that
>> repository.
>
> yes, this is the intended behavior under Pharo. Why? Because everything
> else makes Monticello unacceptably slow.
>
> Monticello is "wrong" in this case by relying on a "unique" version name,
> which it approximates by checking known repositories (works well for small
> projects, but does not scale at all, nor does it give any guarantee of
> being uniqe).
>
> That is the first report of such an issue since I changed the code there.
> Hence I don't see an urge to change it.