I'm sorry about that. This is true that the addition to MC are quite draft but useful and not tested on large scenario. I imagine myself really doing the same. On Apr 19, 2009, at 5:43 PM, Nicolas Cellier wrote:

I experimented other unaware beotian stupid manipulations (just to workaround the oter bug) :

1) modify Kernel 2) add a SLICE-A requiring Kernel 3) Publish SLICE-A -> SLICE-A.1 Kernel.1 4) modify Kernel again 5) add a new SLICE-B requiring all dirty packages, that is Kernel and SLICE-A 6) Publish SLICE-B -> SLICE-B-1 Kernel.2

Now SLICE-B.1 depends on SLICE-A.1 and Kernel.2 BUT SLICE-A.1 depends on Kernel.1

7) quit the image, restart and load SLICE-B.1

Doing this, I ended up with Kernel.1 in the image... GRR

My advice is: if your changes in simple and touch only one package don't bother create a slice even if this is cool because I clean regularly the inbox and sometimes it is difficult to understand what is what. if your changes touched a lot of package slice is important. Stef

2009/4/19 Stéphane Ducasse <stephane.ducasse@inria.fr>:

...

No and I'm expert in stupid manipulations and computer freezing :) but did not succeed this one On Apr 19, 2009, at 4:41 PM, Nicolas Cellier wrote:

...

Did anyone experimented an Infinite loop in Monticello MCWorkingCopy needsSavings ?

I had a SLICE previously saved. I added a new required pakage dependency to this SLICE. I tried to save again -> InfiniteLoop...

_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project