I think that I finally got it.
Here is the scenario
Project A depends on project B.
A 1.0 depends on B 1.0
A 2.0 depends on B 2.0
A 1.0 provides extensions to a class which is present in B 1.0 but removed in B 2.0.
If A 1.0 is present in the image, and A 2.0 is loaded, packages from B 2.0 are loaded before the ones of A 2.0. To the class get’s removed, and the extension methods that disappeared with its removal are considered as local changes.
This means that there is no way to do a clean update via catalog browser?
Uko
> On 27 Oct 2015, at 07:23, Thierry Goubier <
[hidden email]> wrote:
>
> Le 27/10/2015 03:40, Chris Cunningham a écrit :
>> you could try Merging instead of loading, and then look at the
>> difference between the newly merged in-image package and version 74.
>>
>> Or, you could open the Monticello browser, highlight the package (which
>> you've already done),and click on Changes to see what you've changed
>> since version 73.
>>
>> Or, maybe gitfiletree has so changed Monticello behaviour that neither
>> of these work anymore?
>
> In that, GitFileTree has not changed Monticello behavior, so those operations should work.
>
> Thierry
>
>> In any case, if you try to load over your changes, it doesn't give you
>> any hint as to what it is loading over.
>>
>> -cbc
>>
>> On Mon, Oct 26, 2015 at 6:14 PM, Yuriy Tymchuk <
[hidden email]
>> <mailto:
[hidden email]>> wrote:
>>
>> Ok, I’m completely exhausted, I have no clue what’s the problem.
>>
>> I have version 73 of my package, I load version 74 an then it says:
>> “If you continue, you will loose these changes: “ and there is
>> nothing more, there are no changes that I’m going to loose. Is there
>> any way to identify why the merge is happening. Yes, maybe it is
>> because I am using gitfiletree, but how do I find out the reason of
>> merge? Monticello is an amazing tool because it keeps my hands tied,
>> as I cannot really debug why there is a merge (it’s too complex at
>> least for me).
>>
>> Uko
>>
>>
>
>
Locked
