Sharing nested projects can lead to issues

[tobous]

In Eclipse, nested projects lead to a workspace setup where resources are listed twice (or more often with more levels of nesting): Once as part of their own project and once as part of the project they are actually located in (when looking at the project in the file system).

Example: Filesystem view:

 project_a
  |--- resource_a-1
  |--- resource_a-2
  \--- project_b
         |--- resource_b-1
         \--- resource_b-2

Project view:

project_a                               (<- seen as project)
  |--- resource_a-1
  |--- resource_a-2
  \--- project_b                        (<- not seen as project)
         |--- resource_b-1
         \--- resource_b-2

project_b                               (<- seen as project)
  |--- resource_b-1
  \--- resource_b-2

(As a real example, you can have a look as the Saros Project repo, more specifically the project "saros.eclipse" and its nested project "Saros Feature". I tested this using the "feature.xml" file, but creating a test text file in the folder is easier.)

With the current project sharing logic, sharing such nested projects can break in different scenarios.

1. When creating the shared projects as part of the incoming project negotiation

If the shared projects are created as part of the incoming project negotiation, the resources of the nested project are created twice on the client side. Once for the project view of the project and once as normal resources in the parent project.

In general, this is an issues as it means that the project is not set up correctly on the client side since these now duplicated resources were actually meant to be represented by a single file in the filesystem.

Furthermore, this leads to issues during the session if one of the two resources is modified on the client side. As both resources in the original project on the host side are represented by the same file in the file system, the changes will be applied to both files. On the client side, however, this is not the case as the resources are separate, leading to a desynchronization (as the file content of the second representation of the file no longer matches for the host and client; modified for host, not modified for client).

2. When modifying such a doubled resource with both editors open

In this setup, both host and client already have the complete and correctly set up project before the session start. The session is started normally on all projects. Both participants then open both editors for a duplicated resource (meaning an editor for the resource in its actual project and an editor for the resource as part of its parent project).

If one of the open editors is now modified and saved, the content of the file is duplicated (i.e. is now contained in the file twice). I am not sure whether the content is entirely or only partly duplicated as I haven't spend that much time testing it. I am also not quite sure what setup is needed for this to occur. It is a bit inconsistent but it still happens almost every save for me.

[tobous]

I encountered this problem while thinking about the new resource design (a.k.a. introducing reference points or whatever you want to call it).

For the first design, I am planning to exclude this problem (as it is only an edge case scenario in my opinion), but it should be addressed at some point.

But in general, I am not sure what to do about this (besides not allowing nested projects to be shared). @srossbach Any ideas?

[srossbach]

If file deltas are generated twice we are really out of luck because it is possible that they arrive in chunks and so we cannot filter them out correctly.

Do you have any logs that contains such deltas ?

[tobous]

Yes, but the log is quite long (~12000 lines). I triggered the issue multiple times in both sides with both editors. The test were done on the current master.

Setup: Alice and Bob import the Saros project, both create the file /saros.eclipse/feature/test.txt with the content "Hallo Welt", and then start a session with the projects saros.eclipse and Saros Feature. They then both open both editors for /saros.eclipse/feature/test.txt and modify and save the different editors sequentially. There never way any concurrent editing going on. The file was always saved before it was modified through another editor.

[email protected]_2020-03-31_21-16-58.log [email protected]_2020-03-31_21-17-02.log

I will upload a shorter version of the logs (where the issue only occurred once) later today.

[tobous]

Sorry, forgot to do the tests yesterday. Here are the results of a shorter test run. The setup is the same: Alice (host) and Bob start with the Saros project already present and in sync (containing the additional test resource /saros.eclipse/feature/test.txt). They share the projects saros.eclipse and Saros Feature. Both also have the editor for both versions of test.txt open (before the session start in this case, but I don't think it matters).

In this test, Alice typed "broken" into the editor for the representation in the saros.eclipse project and saved. This lead to a duplication of the entire file content. Furthermore, the file content was completely marked as a remote addition for Alice.

The session was ended shortly after the session end, still leaving the editors for Alice in an unsaved state. The editors for Bob, however, were not in an unsaved state.

Log files: [email protected]_2020-04-02_13-21-42.log [email protected]_2020-04-02_13-21-43.log