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 <[email protected]> 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 <[email protected] >> <mailto:[email protected]>> 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 >> >> > >
