This document should describe the current state of the ideas and designs for a synchronization based file access for remote projects. This document in it it's original version has been created by Roland Schulz based on discussions on bug 316709.
Both RemoteTools and RSE use SFTP to access files when editing them. This has several disadvantages:
- Working on files when not connected to the internet
- Responsiveness of UI
- Not all PTP functions are supported using RemoteTools/RDT
The Eclipse core and CDT doing most of the file operations in the main thread (assuming that all file operations are low latency). This causes a responsiveness problems with a remote file system.
Because the file operations are in the main thread they block the GUI until the IO operation finishes and thus preventing the user to continue the work while the IO operation is running. It also often prevents IO operations which could run in parallel to do so. See Bugs 160353, 177994, 195997, 218387, 219169 and wiki.eclipse.org/TM_and_RSE_FAQ from the RSE team regarding the same problem for RSE. Their seems to be no work-around for this problem. While it seams in theory to be possible to improve it somewhat by using Display.readAndDispatch, it is not advised and has been removed from RSE (160353). Having a responsive UI is considered by many extremely important thus this is an important point.
It is very unlikely, at least for the medium-term (meaning the next Eclipse release in 2011), that both Eclipse Core and CDT move all file operations into threads and hide latency by doing IO operations in parallel. Therefore a different approach is needed to have s performant remote IO method.
Prior Eclipse efforts
- rsync file subsystem Bug describing ideas to implement rsync based back-end for RSE
- Use rsync to sync the remote workspace to the local machine FAQ including disadvantages and advantages of using Rsync for a remote project
- PTP/photran/rsync remote projects
- Rsync-style Remote Project Support for Photran
- Remote Include Path Support
Advantages of Rsync
Disadvantages of Rsync
- no JAVA implementation is available
- the synchronization is only one-way
The later is important if, either automatically or by the user, remote files get changed. The one-way synchronization of rsync would usually not synchronize changes to the client and would not detect conflicts caused by changes on both sides very well.
Advantages of GIT
- It has a java implementation (shipping with Helios)
- is known to be extremely fast (including the java implementation)
- supports two way synchronization.
Of course GIT is not meant as a synchronization tool (but a DCVS) but it works as a synchronization tool extremely well. Using git for synchronization would work both for those users using it also for version control and for those users using some other tool for version control. As an example a remote synchronization of a folder containing ~4000files (1 changed - which unknown to GIT), ~100MB, where GIT detects file changes on both sides, over a remote connection (cable), takes less than one second. The performance is mainly limited by the file system for the tree traversal.
Local indexing should be supported. Should we also support remote indexing? Local indexing requires remote include files.
Support for other Remote Tools besides Build