Mariano Martinez Peck wrote:
Hi Tim,

Normally...a load simply loads that version you are telling to load. If you have local changes in any of the packages you will be loading, those changes will be LOST and overridden with the ones of the version you are loading. If you load via Monticello...if usually checks if you already have changes in the packages you are about to load and warns you or directly recommends you to merge (it depends which Pharo version you are working on).

The merge...is for when you have local changes in that package you will load. Hence, the merge is the way so that you can merge your local changes and the changes coming from the new version you are about to load. It might have conflicts which need to be resolved. After you have merged, then you can commit your changes if you want.


Also, its not necessarily your own changes that are lost, but if two people both start from version A to produce unrelated versions B and C,�� then "load"ing B�� then "load"ing C will remove the changes of B, whereas a merge will give you both B and C. [1].�� Now Monticello will show you that B is not loaded by displaying it in bold in the respository view listing all packages.�� You can try this yourself by starting with your own package version A, make some changes and save version B, "load" A back, make some changes and save version "C".

[1] http://www.lukas-renggli.ch/blog/monticello-merging


Also, note that you may also be trying to commit and there is a new version of the package from the one you started to change. Therefore, if you commit, you will override last version. Here, again, Monticello usually warns you. So what you would normally do here is a marge again, so that the changes from the last version gets merged with your local changes. After, you can commit without problems.

Hope this is clear.��

Cheers,��

��


On Thu, Aug 7, 2014 at 1:15 PM, Tim Mackinnon <tim@testit.works> wrote:
Hi - I am still a bit confused about the difference between load vs. merge with Monticello?

Last month, when I tried to verify a bug fix, I did a load - and it caused other things (dependencies?) to be loaded into my clean image and so I ended up with something else in a broken state. So I had to do a Merge - get just the specific fixes and I could prove everything worked.

Yesterday however I wanted to test a fix Damien made for ��bug��13526. But when I Merged it, I hit a DNU and then noticed he had put the following comment (Slice .2 depends on 13787).��
So I repeated the same merge step for 13787 and it then worked (apart from another edge case I found and he has now fixed).

But this has got me thinking, I don���t really understand the difference between merge/load. Can someone explain it to me in the above context? Should I have�����loaded��� 13526 so that it pulled in the dependency��indicated? (I notice in the slice description - it shows -��Dependencies: Tool-Base-DamienPollet.24). I thought Monticello managed dependencies - so now I���m confused why I need to do Merge anyway?
Monticello handles dependencies at the package level.�� Its question of whether those dependencies are merged into the existing system of overwrite the existing system. At a guess Monticello "Dependencies" were originally used a lot prior to Metacello (but that is before my time).�� I've never seen a Monticello dependency used outside of Slices (but that could be my own small world view).�� A Slice uses the "Dependencies" mechanism to pull in the packages that need to go together for "one fix".�� The dependency Damien mentions is currently a very manual dependency, but maybe we should consider making one slice depend on another - though I'm not sure how load order would be handled.

For your example, you would need to manually load slice 13787 and slice 13526 then do you testing.�� It would be useful to report in issue 13787 that is works with and facilitates issue 13526.


Related to this, when the next�����release��� image gets built - how are these slices assembled such that��Tool-Base-DamienPollet.24 is correctly loaded in release image?

Each Pharo build (usually daily if not more) integrates selected slices on a continuous basis.�� In [pharo-dev] maillist you will see automated posts like [2] where for that example, three slices have been integrated into build 40161.������ The integration action is currently performed manually by a small number of the core team.�� That might be bottleneck, but consider that over 12 months for Pharo 3 there were 2300 issues/slices integrated [3].�� A more automated integration system might be desirable, but is not there yet.

[2]
Subject: [Pharo-dev] [pharo-project/pharo-core] 5323b0: 40161
Log Message:
�� -----------
�� 40161
13795 Browsing certain classes takes several seconds
������ https://pharo.fogbugz.com/f/cases/13795

13800 another small SystemNavigation cleanup
������ https://pharo.fogbugz.com/f/cases/13800

13798 empty package UI can be deleted
������ https://pharo.fogbugz.com/f/cases/13798


[3] http://pharo.org/news/pharo-3.0-released
cheers -ben


Thanks for any help.

Tim



--
Mariano
http://marianopeck.wordpress.com