RE: [mylar-dev] commit set management and ui

["Mik Kersten" <beatmik@xxxxxxx>]

> -----Original Message-----
> From: mylar-dev-bounces@xxxxxxxxxxx [mailto:mylar-dev-bounces@xxxxxxxxxxx]
> On Behalf Of Eugene Kuleshov
... 
> Initially I've noticed empty mylar's commit sets on a sync view that are
> created
> on context activation. It doesn't seem right and commit set should be
> only there if there are changes.

This sounds right, and it pushes on an important limitation of Mylar--only
information about the current context is in memory.  So either the Change
Set manager will need to persist this information (easy), or Mylar needs to
persist contexts.  I think that the latter is inevitable to support things
like having an aggregate context for a category or for the workspace (e.g.
to ensure that commonly used APIs are on top of the content assist list even
if they aren't in the current context).  
 
> Also, commit set created even for projects and working sets on a sync
> view which are not under CVS control.

Please file this as a bug.

> Another important issue is what to do about resources that are modified
> but not 'touched'.
> E.g. if you refactor something, the affected resources won't be part of
> the commit set and should be.
> Similary resource could be added or changed externally (new files,
> sources and resources
> generated by other tools including javacc, xdoclet, etc) and discovered
> by Eclipse on explicit refresh.

We could give resources modified indirectly (e.g. by refactoring) a
predicted interest.  The thing that still seems unclear is what happens when
the interest of those resources decays.  Currently they will be taken out of
the change set, but that seems wrong because they have been modified.  I see
two possibilities:
1) Resources that have been edited either directly or indirectly can not
decay below the "interesting" threshold.
2) The Change Set is a projection of the context model that doesn't 'see'
the decay and considers any element in the model interesting.

(1) seems right for directly modified resources.  It could also be right for
indirectly modified resources but what concerns me is that a bunch of
refactoring will overpopulate the Package Explorer.  So it may have to be a
combo of both.  The corresponding bug is:

https://bugs.eclipse.org/bugs/show_bug.cgi?id=117352 

Mik

--
Mik Kersten, http://kerstens.org/mik
Mylar project lead, http://eclipse.org/mylar