Some Eclipse Foundation services are deprecated, or will be soon. Please ensure you've read this important communication.
Bug 212078 - [prov] Timed retention policy for artifact GC
Summary: [prov] Timed retention policy for artifact GC
Status: CLOSED WONTFIX
Alias: None
Product: Equinox
Classification: Eclipse Project
Component: p2 (show other bugs)
Version: 3.4   Edit
Hardware: PC Windows XP
: P3 enhancement (vote)
Target Milestone: ---   Edit
Assignee: P2 Inbox CLA
QA Contact:
URL:
Whiteboard:
Keywords:
Depends on:
Blocks: 211346
  Show dependency tree
 
Reported: 2007-12-05 16:55 EST by Allan Godding CLA
Modified: 2011-06-12 21:48 EDT (History)
4 users (show)

See Also:

Attachments
Retention Policy patch (48.86 KB, patch)
2007-12-10 13:51 EST, Allan Godding CLA 		no flags Details | Diff
Updated patch (61.39 KB, patch)
2007-12-17 10:07 EST, Allan Godding CLA 		no flags Details | Diff
patch for p2.garbagecollector (29.07 KB, patch)
2007-12-17 10:29 EST, Allan Godding CLA 		no flags Details | Diff
updated patch (59.63 KB, patch)
2007-12-19 13:00 EST, Allan Godding CLA 		no flags Details | Diff
Updated patch (70.33 KB, patch)
2007-12-21 15:20 EST, Allan Godding CLA 		no flags Details | Diff
Show Obsolete (4) View All Add an attachment (proposed patch, testcase, etc.)

Note You need to log in before you can comment on or make changes to this bug.
Description Allan Godding CLA 2007-12-05 16:55:37 EST 
Currently being worked is an option to have the garbage collector keep inactive artifacts in the file system for a user-specified length of time after they have been deemed inactive (garbage).
Comment 1 Susan McCourt CLA 2007-12-05 22:33:41 EST 
I'll add prefs to the sdk UI when this goes in...
Comment 2 Allan Godding CLA 2007-12-10 13:51:23 EST 
Created attachment 84884 [details]
Retention Policy patch

This patch contains all of the necessary functionality for the GC timed retention policy.  It has not yet been properly tested or reviewed.

Susan: I've included some simple preferences in the ProvisioningPreferencePage for the retention policy stuff, mainly for my own testing purposes.

As a reminder to myself, ensure that PolicyManager.RETENTION_POLICY_MS is set to represent days instead of seconds before the code is checked in.
Comment 3 Allan Godding CLA 2007-12-17 10:07:58 EST 
Created attachment 85382 [details]
Updated patch
Comment 4 Allan Godding CLA 2007-12-17 10:29:54 EST 
Created attachment 85384 [details]
patch for p2.garbagecollector
Comment 5 Allan Godding CLA 2007-12-19 13:00:45 EST 
Created attachment 85585 [details]
updated patch
Comment 6 Allan Godding CLA 2007-12-21 15:20:13 EST 
Created attachment 85739 [details]
Updated patch

This patch contains some changes to the structure of the retention policy system.  I have also included JUnit tests.  Some work still needs to be done to allow the time retention policy to persist its information across sessions.
Comment 7 Glen A. CLA 2008-06-04 13:01:46 EDT 
Copied from bug #95282:

***
I like to keep one or two of the previous versions of each feature in case I
need to rollback in situations where conflicts occur or where the later version
is experimental.

What I suggest is to allow the user to specify the number of previous versions
he/she wishes to keep, and to remove all other versions when an update occurs.
This setting could be specified in Preferences -> Install/Update.
***

The above was for the 'old' update manager. This bug is similar, but I don't think it covers what I refer to. My idea is version based retention, this is time based retention.

The release cycles of various plug-ins differ – if there is a relatively large gap between releases, the previous versions of my plug-ins will be deleted, making rollbacks impossible.
Comment 8 Pascal Rapicault CLA 2011-06-12 21:48:21 EDT 
No plan to fix this