Hi,
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.
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.
How is Eclipse Change Set related to Changelist from subversion 1.5?
Regards,
Martin
Mark Phippard píše v Čt 06. 11. 2008 v 09:30 -0500:
> I do not recall who wrote our code in this area, but they undoubtedly
> just used the CVS implementation as a guide, which is also why certain
> team internal classes are used. I am not sure if there will be any
> problems with copying their classes. I am a little concerned that
> there might be a problem as that is what we would typically have done
> in the past (and did not in this case). It is possible though that it
> just gets really messy (copying one requires copying another etc..).
>
> In terms of the logic inside the Eclipse Team class, that is not
> something I can comment on. I believe that Eclipse is not supporting
> most of this code any more, which is why they refused requests to make
> the API public. Still, you might get answers if you ask.
>
> Does the existing code specifically descend into derived folders? My
> guess is that the code is just "lazy" and not ignoring stuff that it
> ought to be ignoring.
>
> Mark
>
>
> On Thu, Nov 6, 2008 at 9:36 AM, Martin Kočí <Martin.Koci_at_aura.cz> wrote:
> > Yes, I will do that.
> >
> > But I'm still not sure if it's a bug or a feature. So I am asking you -
> > subclipse = svn team provider - developers if there can be any real
> > situation where notification of changes in derived folder can be useful.
> > The convention for team providers is skipping them in synchronize view
> > so I dont see any reason for computing their state with Subscriber.
> >
> > As I am looking in cvs/subversive plugins all of them are using this
> > SubscriberResourceCollector. But in cvs plugin computing of state takes
> > minimal CPU so users can notice a performance impact only on real big
> > projects.
> >
> > With subversive is the situation same or worse as with subclipse - build
> > takes many times more CPU.
> >
> >
> > First shot idea: if I modify
> > org.eclipse.team.internal.core.subscribers.SubscriberResourceCollector.processDelta(IResourceDelta, IResource[]) method as:
> >
> > // Skip derived folders: << PATCH >>
> > if (resource.getType() == IFolder.FOLDER && resource.isDerived()) {
> > visitChildren = false;
> > }
> >
> > // Handle changed children
> > if (visitChildren || isAncestorOfRoot(resource, roots)) {
> > IResourceDelta[] affectedChildren =
> > delta.getAffectedChildren(IResourceDelta.CHANGED |
> > IResourceDelta.REMOVED | IResourceDelta.ADDED);
> > for (int i = 0; i < affectedChildren.length; i++) {
> > processDelta(affectedChildren[i], roots);
> > }
> > }
> >
> > it solves our problem.
> >
> >
> > Mark Phippard píše v Čt 06. 11. 2008 v 09:01 -0500:
> >> Can you open an issue in our tracker and attach a patch that
> >> implements your proposed solution?
> >>
> >>
> >> On Thu, Nov 6, 2008 at 8:58 AM, Martin Kočí <Martin.Koci_at_aura.cz> wrote:
> >> > Hello,
> >> >
> >> > I've noticed that SVNActiveChangeSetCollector listens (=processes
> >> > deltas) for all resources in derived folders.
> >> >
> >> > In my case it means processing of thousands .class files in
> >> > target/classes or target/test-classes (it's standard maven layout). This
> >> > takes amount of CPU time - for example, build of one of our project
> >> > takes one minute without subclipse installed and 5 minutes with
> >> > subclipse.
> >> >
> >> > The problem (or is it a feature? ) is not in subclipse itself, but in
> >> > org.eclipse.team.internal.core.subscribers.SubscriberResourceCollector.class which comes from (internal?!) org.eclipse.team.
> >> >
> >> > That class - SubscriberResourceCollector - visits children of all
> >> > derived folders. I think this feature is unintenional or can be
> >> > optional.
> >> >
> >> > Please notice that there was a similar bug in Mylyn:
> >> > https://bugs.eclipse.org/bugs/show_bug.cgi?id=195229 ; I've fixed that
> >> > with skipping all derived folders - see attached patch at that bug.
> >> >
> >> >
> >> > And now what we (or at least me) can do with this problem. Unfortunately
> >> > class hiearchy SubscriberChangeSetManager -> ActiveChangeSetManager does
> >> > not allow any override of SubscriberResourceCollector - creation of that
> >> > instance is completely private. It means either copy those two type in
> >> > subclipse or open a bug et eclipse.org. But the second second solution
> >> > can take years to solve.
> >> >
> >> >
> >> > What do you think? Or am I completely wrong?
> >> >
> >> >
> >> > Regards,
> >> >
> >> >
> >> > Martin Kočí
> >> >
> >> >
> >> >
> >> >
> >> >
> >> >
> >> > ---------------------------------------------------------------------
> >> > To unsubscribe, e-mail: dev-unsubscribe_at_subclipse.tigris.org
> >> > For additional commands, e-mail: dev-help_at_subclipse.tigris.org
> >> >
> >> >
> >>
> >>
> >>
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe_at_subclipse.tigris.org
> > For additional commands, e-mail: dev-help_at_subclipse.tigris.org
> >
> >
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe_at_subclipse.tigris.org
For additional commands, e-mail: dev-help_at_subclipse.tigris.org
Received on 2008-11-13 14:18:21 CET