Community
Participate
Working Groups
As we move to 2.1 there will be people using both 2.0 and 2.1 on the same projects. In 2.1 there is some new metadata in the .projects files. Since these files are shared, we should investigate and document the behaviour people can expect. For example assume user 2.1 gets a project and updates something captured in new .project metadata (e.g., linked resources). She then releases this to the shared repo. User 2.0 comes along and checks the project out. What happens? Does it work and the extra data is ignored? If not, what is the failure mode? Are there any workarounds? Assuming it is ok or can be worked around, 2.0 then updates something in the project that rewrites the .project file. Is the 2.1 data preserved? They then release the changes. What happens to 2.1 when she catches up to the changes? What happens to another 2.1 user who then loads the project for the first time?
See also bug 29578
I would presume that the 2.0 image could read the data ok (extra elements would be ignored) but when the .project file was written out again (by a call to #setDescription) then the 2.1 data contained in the file would be overwritten and lost. Will investigate to ensure that is the case.
Rafael please try this and report your findings here. Thanks.
Steps executed: 1 - Created two projects ProjectA and ProjectB in a 2.1 workspace 2 - Released both projects to a CVS repository 3- Checked out both projects into a 2.0 workspace 4 - Created linked folder in 2.1 workspace in ProjectB 5 - Released changes to repository 6 - Updated 2.0 workspace with changes from the repository. Project description file contains elements related to linked resources, which are ignored. 7 - In 2.0 workspace, added reference to ProjectA in ProjectB. Project description file is rewritten and elements related to linked resources discarded. 8 - Commited changes in the project (including the .project file) from the 2.0 workspace to the repository 9 - From the 2.1 workspace, checked out changes in the repository - ProjectB does not have a linked folder anymore. From a resource management perspective, no failures will happen. But if the linked resources are required for the project to work (is a folder containing project source files, or is a referenced library, or contains files required by some builder) or are exported and used by other projects, errors will arise. The same sort of things will happen to a 2.1 user that checks out the project for the first time. Currently, the workaround consists in selectively releasing changes to the project description file from a 2.0 workspace to the repository or selectively bringing changes to the project description file from the repository to a 2.1 workspace. If users use commit/update instead with "Synchronize with Repository" or "Synchronize Outgoing Changes", that cannot be done (unless the user selects which files/folders should be commited/updated instead of selecting the whole project). The caveats are the additional complexity when releasing/bringing changes and the requirement that users understand the project description file structure (which is simple). Also, a convention about what is the "official" version that should be in the repository may help. Or a convention that only 2.1 users should change the project properties.
Adjusting milestone. We will leave this bug report open for now so we have a reference when addressing these types of issues in the README and other doc.
Addressed in section 6.1 in the README file (Interoperability of Release 2.1 and 2.0 -> Sharing projects between heterogeneous Eclipse 2.0 and 2.1). Closing.
