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

["Mik Kersten" <beatmik@xxxxxxx>]

For tomorrow evening's 0.4.4 release this will work as suggested by the very
useful comments on https://bugs.eclipse.org/bugs/show_bug.cgi?id=117352

Details will be in the New & Noteworthy, but in short the context change
sets persist across task activations and don't 'see' decay.  Regarding (1)
below Mylar now listens to resource deltas, but the only elements
automatically added to the context are newly created resources and elements
manually forced into the active context change set (via the Synchronize
view).  It will now be straightforward to have other kinds of resource
deltas induce interest as needed (e.g. refactorings, marker changes).  But
until there are clear use cases we should hold off on that.  I could imagine
some future MDD-style scenarios where editing one resources generates others
that become interesting but aren't considered derived resources...

Mik

> -----Original Message-----
> From: mylar-dev-bounces@xxxxxxxxxxx [mailto:mylar-dev-bounces@xxxxxxxxxxx]
...
> 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