Some Eclipse Foundation services are deprecated, or will be soon. Please ensure you've read this important communication.
Bug 10011 - Team 2.0: Decorators for outgoing changes sometimes incorrect
Summary: Team 2.0: Decorators for outgoing changes sometimes incorrect
Status: RESOLVED DUPLICATE of bug 3979
Alias: None
Product: Platform
Classification: Eclipse Project
Component: Team (show other bugs)
Version: 2.0   Edit
Hardware: PC Windows 2000
: P3 normal (vote)
Target Milestone: ---   Edit
Assignee: Kevin McGuire CLA
QA Contact:
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2002-02-20 06:28 EST by Leon J. Breedt CLA
Modified: 2002-09-09 14:16 EDT (History)
0 users

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Leon J. Breedt CLA 2002-02-20 06:28:02 EST
Build: 20020214

Details:
The decorators for outgoing changes sometimes show changes for packages which 
have no changed files in. I guess this is maybe because they're below the 
actual changed packages in the physical directories.

Example:
Change a file in package v.w.x.y.z.

The packages v.w.x and v.w.x.y also get a decorator for outgoing changes, 
although expanding them shows none of the files in it have changed. This is 
misleading.
Comment 1 Leon J. Breedt CLA 2002-02-20 06:28:58 EST
Clarification: The report refers to decorators in the Java Package view.
Comment 2 James Moody CLA 2002-02-20 11:37:51 EST
Yes. I believe this likely will not be fixed for 2.0. Technically it is true 
from the point of view that package fragments adapt to IFolders, and those 
particular IFolders are dirty because their children are dirty. The problem is 
that package fragments are semantically shallow, and folders are semantically 
deep, and since decorators are contributed to resources, you get the folder 
behaviour instead of the desired package fragment behaviour. This is a 
complicated problem that we have given a lot of thought to (mapping of logical 
resources to physical resources) but I think that any really correct solution 
will be much to complicated to include in 2.0.
Comment 3 Jean-Michel Lemieux CLA 2002-02-25 17:00:44 EST
As James has pointed out, we would really like to address this problem, but it 
won't be done in the 2.0 timeframe.
Comment 4 Michael Valenta CLA 2002-09-09 14:16:05 EDT
Reopening
Comment 5 Michael Valenta CLA 2002-09-09 14:16:47 EDT

*** This bug has been marked as a duplicate of 3979 ***