Conference iosg::all-in-1_v30

    Ben,
    
    Are you also reporting these CM+ opportunities formally?
    
    Regards,
    
    Andrew.D.Wicks

    Ben,
    
    Just out of interest you mentioned in your base note the two options
    you found for doing this reapplying of customisations but I wonder to
    what extent a co-existent system would have helped.
    
    To begin with you'd have the v2.4 base element, the v2.4 site element
    and the v3.0 base element all accessible to you and you could
    presumably create an application area under v3.0 that was actually your
    ALL-IN-1 v2.4 system.
    
    Then you'd do the differences between the base element in OA and either
    of elements in the V24_OA application area, reapply the customisations
    on your v3.0 system to give you the v3.0 site elements you want.
    
    Then since you have to blow away your v3.0 system you package up the
    elements and store them - save the .FGN file - do the upgrade and then
    restore the application.
    
    Not having access to a coex system I haven't tried this but it sounds
    feasible and hopefully the other famous dutchmen can confirm this?
                                                          
    regards,
    
    Andrew.D.Wicks

    Ben,
    
    I agree with the need for the option of maintaining the previous
    version somewhere. This will be far easier post V3.0 since we will have
    the application structure in place and all the tools necessary for
    maintaining it (copy across areas, imprt, send to vms etc).
    
    BTW once you retrieved your V2.4 did you not think to try and MERGE
    the elements?
    
    Ciao,
    Kevin

Ben, 

Agreed, we miss such an option indeed.
    
Re .2:

>    Just out of interest you mentioned in your base note the two options
>    you found for doing this reapplying of customisations but I wonder to
>    what extent a co-existent system would have helped.
>    
>    To begin with you'd have the v2.4 base element, the v2.4 site element
>    and the v3.0 base element all accessible to you and you could
>    presumably create an application area under v3.0 that was actually your
>    ALL-IN-1 v2.4 system.
    
The co-ex system will be of help, but I don't think this should be a general
guideline. How many sites will actually install a co-ex system?

However, to continue using a co-ex system, creating a seperate 'ALL-IN-1 V2.4 
area' still involves restoring of the elements from V2.4 into the V3.0 area
(although the benefit is that the files are still available on the system).
This due to that the OA$SITE_DEV_<application area>: can refer to the V2.4
existing directories and files, but no element records are available in
CM$SITELOG or CM$SDC, which are needed to get proper differences (the option
DIFA (differences with any file) would be somewhat difficult for Named Data
e.g.). 

The Receive area can be used to 'Receive the V2.4 base elements into CM'. I 
wouldn't try to make them proper Base elements by Moving them to Base, as this
could involve the exercise of defining valid Live and Base locations, actually
moving them there, etc. just for the benifit of making it Base elements. 
Having the elements in CM allows for running differences AND using the option
MBE (Merge with Base element). Before starting the last options, make sure your
CM working conditions (CM SCE SWC) are set correctly: 

	Pre-upgrade merge: Y 
	Merge element in CM database: Y

(Yes, pre-upgrade merge is set correctly. It will act correctly in assuming
that you're performing a Post-upgrade merge. The bug has been recognized).

Select your Site element, perform option MBE, and select the element in the
V2.4 application area as the 'Old element'.

If the differences have been processed then continue as Andrew indicated 
(packaging, ect.).

Ciao,

	Simon

	Kevin,

	No I did not try MERGE, as I thought (and still do) that when you coded
	this option years ago, it was based upon a CMS feature.

		Ben

	

    
    Hi Ben,
    
    > ...it was based upon a CMS feature.
    
    Indeed it is using the CMS VARIANT 'feature'. But why 'feature'? I
    still think it is part of the real CMS functionality.
    
    Ciao,
    
    	Simon