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 pe 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
>
>
--
Thanks
Mark Phippard
http://markphip.blogspot.com/
Received on 2008-11-06 15:31:09 CET