Panagiotis Korros wrote:
>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
>
>
>
Ok !
Thank you for your help.
Cédric
Received on Sat Oct 30 19:45:14 2004