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

make subclipse concurrent

From: Panagiotis Korros <panagiotis.korros_at_gmail.com>
Date: 2004-10-30 09:39:08 CEST

Hi to all,
I had been away for a while, I hope to be able to contribute more the
next months.

I would like to start new work on making subclipse to be more 3.0
aware. This includes using background jobs, for the major operations,
to improve the overall concurency.

I think that concurrency is very important especially for the length
operations. My aim is to make subclipse at least as concurrent as the
CVS plugin.

In Eclipse 3.0 the CVS operations api
(org.eclipse.team.internal.ccvs.ui.operations) uses the
org.eclipse.team.ui.TeamOperation class that executes the code us an
backgroundable job.
This code uses the jobs api internally and also uses fine frained
sheduling rules that locks only the part of the workspace that is
affected by the current operation and allows to work on other parts of
the workspace concurently.

I started porting this code to subclipse but run into trouble because
the ISVNCommand commands use the SVNProviderPlugin.run() method to run
jobs and this method locks the entire workspace.

I propose to incrementally remove the call to SVNProviderPlugin.run()
calls from ISVNCommand implementations and provide subclasses of
TeamOperation to handle the command execution.
For each command there should be a corrensonding operation and only
the operations should be called from the ui.
e.g. the UpdateResourcesCommand should have an corrensonding UpdateOperation

This is on par with the current cvs plugin implementation.

Is it ok to proceed to these changes?

Regards,
Panagiotis Korros

-- 
Take back the web http://www.getfirefox.com
Received on Sat Oct 30 17:39:08 2004

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.