On Thu, Nov 13, 2008 at 8:34 AM, Martin Ko <Martin.Koci_at_aura.cz> wrote:
> I have more informations about this problem.
>
> There are at least three IResourceChangeListeners running during
> workspace build.
>
> 1) FileModificationManager from org.tigris
>
> 2) TeamPrivateListener from org.tigris
>
> 3) SubscriberResourceCollector from org.eclipse.team inicialized from
> Subclipse
>
> All three are processing the same tree of deltas (same
> IResourceChangeEvent instance). Visiting resources deltas is cheap but
> not completely free - best performace can be achieved with one resource
> change listener per subclipse.
It is certainly something we have considered, but any performance
benefit would seem to be marginal at best and the tradeoff is code
maintainability.
> I propose:
>
> - Merge FileModificationManager and TeamPrivateListener into one
> SubclipseResourceChangeListener
>
> - Modify SubclipseResourceChangeListener to skip derived resources
>
> - recode all about ChangeSet for SubclipseResourceChangeListener and get
> rid of org.eclipse.team.internal
>
>
>
> Questions:
>
> Are there any public APIs for Eclipse Change Sets feature? I seems many
> of them are only internal.
The Change Set stuff is not public API and apparently Eclipse does not
plan to ever change this. There are open issues in Eclipse bugzilla.
> How is Eclipse Change Set related to Changelist from subversion 1.5?
They pre-date the feature. We have not updated Subclipse to co-exist
with those new API's yet:
http://subclipse.tigris.org/issues/show_bug.cgi?id=635
There are some differences. For example, SVN does not allow folders
to belong to a changelist and Eclipse does. Also, SVN does not allow
you to set a comment on a Changelist. So we could not rely on SVN
exclusively to store the changelist information. Of course you also
cannot have unversioned items in an SVN changelist.
--
Thanks
Mark Phippard
http://markphip.blogspot.com/
Received on 2008-11-13 14:46:53 CET