Summary: | Issues with migrating shared data | ||
---|---|---|---|
Product: | [Eclipse Project] Platform | Reporter: | Jeff McAffer <jeffmcaffer> |
Component: | Resources | Assignee: | Rafael Chaves <eclipse> |
Status: | RESOLVED FIXED | QA Contact: | |
Severity: | normal | ||
Priority: | P3 | CC: | dj.houghton |
Version: | 2.1 | Keywords: | readme |
Target Milestone: | 2.1 | ||
Hardware: | PC | ||
OS: | Windows 2000 | ||
Whiteboard: |
Description
Jeff McAffer
2003-01-15 16:25:43 EST
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. |