Hi Keith,

I think this is a really good work. We finally have a place with an
up-to-date monticello version. Is loading Monticello-kph.343.mcz the
only thing to do to update everything?

Since I work a lot with traits, I will tell you if your version supports traits.

Thank you very much for your work.

2007/5/11, Keith Hodges <keith_hodges at yahoo.co.uk>:
> I have been fiddling with monticello for an intense couple of days, and
> now I think it works as I always wish it should have done!
>
> For a Monticello revolution check out this version in
> http://www.squeaksource.com/mc
>
> Summary:
>
> * This version for 3.9/3.10 supports pseudo-atomic loading.
> * now up to date with fixes from all over the place.
> * now supports out-of-order package loading.
> * now supports safe package removal
>     i.e. unloading a package does not break other packages.
>
> Caveats: this has not yet been tested with traits
>
> Benefits from the merged version: (should be)
>
> - password manager, does not keep passwords in image.
> - ignore the order of class variables
> - loading FFI external structures
> - copyAll versions from one repository to another
> - ui fixes
> -- bring the tree for dependent packages back
> -- provide more progress information
> -- don't scale the toolbar then resizing the monticello browser
>
> Benefits in addition to those in previous versions:
>
>     * Dont lose your method extensions!
>     * Load/Unload packages to your hearts content.
>     * Edit packages even when all their dependents are not present
>     * Write packages designed to lie-in-wait to enhance other packages
> when loaded.
>
> enjoy
>
> Keith
>
> -------------------
> Details:
>
> I have attempted to merge all of the branches of Monticello and
> PackageInfo that I could find on.
>
> squeaksource/impara/wiresong/squeakfoundation 39a and 310.
>
> This includes latest fixes including the PasswordManager, preamble's
> postambles, support for FFI and the ever so useful copyAll button
>
> It seems also that the impara branch of mc supported the recovery of
> overridden methods, any methods which are 'extended' by another package,
> and categorized with the '-override' suffix, 'should' not be lost when
> you save a package. (I wish someone had told me about this before!)
>
> Out-of order loading of packages, via a new class MCOrphanage.
>
> This enables a package to 'extend', and 'override' methods in
> not-yet-loaded packages, and to subclass not-yet-loaded subclasses. Not
> yet actually loaded ('orphaned') extensions should also save with the
> package so as not to be lost.
>
> To Do: make this loadable into 3.7 and 3.8, since I am using 3.8
> for dev at the moment. See http://bugs.squeak.org/view.php?id=6476
>
> To Do: Test with Traits.
>
> ----------
> TestSpec
>
> Loading a package uses orphanage for not yet loaded items
> Description: When loading a package: Methods and classes which cant load
> go in orphanage. Before loading any package, the orphanage is added to
> the package loader in an attempt to rehome orphans.
>
> Test 1)  out of order loading
> step 1)  load package OrphanageTest-Test1
> Validation: select .Orphanage and 'Browse', there should be 4 orphans in
> total comrising 2 extension methods, awaiting a class, and one class
> awaiting a superclass, and one method of this class.
> step 2) load package OrphanageTest-Test2
> Validation: .Orphanage should contain only 1 extension method awaiting a
> class. System categories 'OrphanageTest-Test1' and 'OrphanageTest-Test2'
> should be populated with the packages.
>
> Test 2) As test 1, but test loading in reverse order.
>
> Unloading package remembers to take orphans as well, and mop up
> When unloading a package: Methods and classes which are in the orphanage
> for that package need to be removed as well.
>
> When a package unloads its classes from the image it removes its own
> methods, but not its extension methods belonging to other packages,
> these need to be mopped up and placed in the orphanage so they are not
> lost.
>
> Classes left without a superclass remain in the image, but the orphanage
> has a class definiton added, ready to relink the class with its
> superclass should it be reloaded.
>
> When browsing or saving, the definitions of such classes should not
> include the 'AnObsolete' prefix. These classes remain in the image and
> can be modified, and remain part of the package as normal.
>
> Testing package removal
> Test 1) package removal - simple case
> step 1) load package OrphanageTest-Test1
> step 2) unload package OrphanageTest-Test1
> Validation: .Orphanage and system category 'OrphanageTest-Test1' should
> be empty.
>
> Test 2) package removal - complex case
> step 1) load package OrphanageTest-Test1 (extends Tests 2 and 3)
> step 2) load package OrphanageTest-Test2 (extends Tests 1)
> step 3) unload package OrphanageTest-Test2
> Validation: This should leave 2 orphaned extension methods awaiting
> their classes, one to OrphanageTest2, the other to OrphanageTest3, there
> should also be a class definition for the 'redefinition' of the now
> obsolete-but-still-present-in-the-image OrphanageTest2Subclass
>
> The system does not return to the exact same state as after step 1,
> because the class OrphanageTest2Subclass having lost its superclass is
> now superclassed by AnObsoleteOrphanageTest2.
> Validation 2: Browse the remaining OrphanageTest-Test1 to confirm that
> the class is depicted without the 'AnObsolete' prefix.
> Validation 2: Select the package click 'Changes' to verify that the
> package is unchanged from the package in the repository.
>
> Test2b) Reload OrphanageTest-Test2
> Validate: OrphanageTest2Subclass now has OrphanageTest2 as a superclass.
> and OrphanageTest2 now has OrphanageTest2Subclass in its subclasses.
>
> Test2c) Unload and Reload OrphanageTest-Test2
> Validate that state is similar to Test 2b)
>
>
>
>


-- 
Damien Cassou