Community
Participate
Working Groups
Install 2.0.2 in C:\2.0.2 C:\2.0.2-eclipse install Alphabet Soup in c:\2.0.2 Start c:\2.0.2 pointing the workspace to c:\sharedWorkspace shutdown start c:\2.0.2-eclipse pointing the workspace to c:\sharedWorkspace open Update Manager revert Eclipse doesn't restart
!CONFIGURATION Oct 10, 2002 12:02:32 PM !ACTIVITY Oct 10, 2002 12:02:34.111 file:C:/202/eclipse/ site-install success !ACTIVITY Oct 10, 2002 12:02:34.391 file:c:/sharedWorkspaceToDelete/.metadata/.config/platform.cfg.metadata/LocalSite.xml reconciliation success !CONFIGURATION Oct 10, 2002 12:04:24 PM !ACTIVITY Oct 10, 2002 12:04:25.441 file:C:/202-eclipse/eclipse/ site-install success !ACTIVITY Oct 10, 2002 12:04:25.651 file:c:/sharedWorkspaceToDelete/.metadata/.config/platform.cfg.metadata/LocalSite.xml reconciliation success !CONFIGURATION Oct 10, 2002 12:02:32 PM !ACTIVITY Oct 10, 2002 12:05:24.726 org.eclipse.jdt.source_2.0.2 feature-disable success !ACTIVITY Oct 10, 2002 12:05:24.726 org.eclipse.jdt_2.0.2 feature-disable success !ACTIVITY Oct 10, 2002 12:05:24.726 org.eclipse.pde_2.0.2 feature-disable success !ACTIVITY Oct 10, 2002 12:05:24.726 org.eclipse.platform.source_2.0.2 feature-disable success !ACTIVITY Oct 10, 2002 12:05:24.736 org.eclipse.platform.win32.source_2.0.2 feature-disable success !ACTIVITY Oct 10, 2002 12:05:24.756 org.eclipse.platform.win32_2.0.2 feature-disable success !ACTIVITY Oct 10, 2002 12:05:24.776 org.eclipse.platform_2.0.2 feature-disable success !ACTIVITY Oct 10, 2002 12:05:24.797 org.eclipse.sdk.win32_2.0.2 feature-disable success !ACTIVITY Oct 10, 2002 12:05:24.716 Oct 10, 2002 12:02:32 PM revert success
I am moving this to a regular 2.0.2 state because we will fix it in 2.0.2 and it is a genuine problem (not a regression). Copying the spec: Configuration compatibility is the property of install configurations that controls whether configuration objects belong to the same linear timeline. The assumption is that configurations in the history are created after incremental changes (feature updated, feature installed, feature configured etc.). Whenever the world changes, triggering full reconciliation, this timeline is lost and we cannot assume that we can safely revert to any configuration before the full reconciliation. For this reason, we will introduce a timestamp in the configuration that will be the timestamp of the last full reconciliation. Only configurations that have the same timestamp can take part in revert operation. Each time a full reconciliation is performed (when startup signals that the platform changed completely), the newly created configuration object will be marked with a timestamp (the actual value obtained by calling System.currentTimeMillis()). Otherwise, the newly created (cloned) configuration object should inherit the value of the timestamp from the object it was cloned from. Here is what needs to be added: 1) A new (internal) field 'timeline' needs to be added to InstallConfigurationModel class. 2) Getters and setters should be added to InstallConfigurationModel (long getTimeline() and void setTimeline(long value)). 2) A new attribute 'timeline' should be added to the configuration XML syntax (root object), be preserved on save and loaded on parse. 3) A new API should be added to IInstallConfiguration: /** * Returns an integer that represents a time stamp created at the beginning of a new configuration time line. * Time line is started when configuration state is created by a full file system reconciliation. All configurations * subsequently created will have the same time line until the next full reconciliation. Certain operations * (e.g. revert) make sense only between objects that belong to the same time line. * @since 2.0.2 * @return the time stamp of the full system reconciliation */ long getTimeline(); When implemented, move it to Update UI for the UI portion of the implementation.
Timeline strategy was too aggressive. Every reconciliation triggered a new Timeline where only the 'optimistic' (i.e the world has changed) should. Other reconciliations (new feature added, plugin removed etc..) are considered recoverable reconciliations. Added some code in SiteReconciler.reconcile(isOptimistic) that sets the timeline of the InstallConfiguration from the previous one if the reconciliation is not optimistic.
tested, you cannot revert if the platform changed, preventing this issue
