[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: [Subclipse-dev] SVNActiveChangeSetCollector listens for changes in derived folders

From: Martin Kočí <Martin.Koci_at_aura.cz>
Date: Thu, 06 Nov 2008 15:36:27 +0100

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
Received on 2008-11-06 15:21:02 CET

This is an archived mail posted to the Subclipse Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.