[eclipse-dev] Clarifying notes on "Important changes in Team, CVS support - natures"
We've received some questions regarding my note on this subject which,
while technically correct, sounded much scarier than intended. I would
first like to apologize for any confusion or concern on this issue; its
really a much simpler matter than it sounds on the surface. It was late
when I sent the announcement :)
======== Quick Answers ========
Q: If I am an existing 2.0 user, what's the easiest way to move to F3?
A: Take a new workspace, checkout the projects you work on. That's it.
Note that taking a new workspace is much easier now in 2.0, since you can
export a Project Set file to describe the source projects you are working
on, and you can also save your preferences external to the workspace.
Q: I don't really want to understand all this nature and properties stuff,
what's the easy answer for F3 and beyond?
A: Ensure everyone on your team has committed their changes, have everyone
take a new workspace, checkout the projects again. You don't need to read
Q: Does this affect 1.0 users moving to 2.0?
A: No, not in the least, regardless of provider. This change only affects
2.0 based workspaces. The conversion steps for 1.0 to 2.0 for CVS users
remain the same, and are described in our FAQ
======== Typical Questions ========
Q: CVS: My CVS menus are gone! What do I do?
A: Don't panic! This means that you are started with a pre-F3 workspace.
You have two choices:
(1) Team->Share->CVS. We will pick up the CVS info from disk and you
will be a 'real' CVS project again.
(2) If you see a menu "Convert Nature to Property", pick this.
Either commit your modified .project or not, whatever works best for your
team (see below).
Q: CVS users: What if I want to keep my workspace?
A: That's easy too. When you startup you will get a menu "Convert Nature
to Property" instead of your CVS menu. Selecting this menu item will
convert that project in your workspace. It will also update your .project
as a convenience, but this isn't necessary for the conversion. More on
.project later in this note. Picking Team->Share->CVS also essentially
does the same thing, but without modifying your .project.
Q: Non-CVS users: What if I want to keep my workspace?
A: Please check with your provider, their conversion strategy likely
Q: Is it a problem if I keep the nature in the .project?
A: No. Updating the workspace is the key here. From thereon you no
longer require the nature in the .project (and its presence won't hurt).
Q: Why should I remove the nature from the .project then?
A: Just to tidy up.
Q: Will removing the nature from the .project "bust" my project in the
A: No, this was strictly a workspace issue.
Q: CVS users: Lets say I remove the nature and commit the .project, what
happens if others on my team take that change?
A: There are two cases:
(1) If everyone is using F3 or later (recommended), then all is fine.
(2) If a teammate can't move to F3+ yet, see last section of this
======== Questions Relevant to those Building Products on Eclipse 2.0
Q: Does this impact other flavours of persisted data?
Q: Will a regular user ever have to do "Convert Nature to Property"?
A: No, this only happens for those who've been taking 2.0 builds. Someone
who takes a product based on the 2.0 GM won't see it.
Q: Is the menu operation "Convert Nature to Property" going to actually be
part of your GM?
A: No, it is there just to help current 2.0 workspace users migrate to the
F3 build. It will be removed prior to GM.
Q: I am concerned about this change occuring so close to the GM. Why, and
how can we have confidence?
When doing the recent target management work it became clear it was highly
likely that a person could, via the target management, blow away the nature
of a project also shared with a repository provider. Exporting/importing
of projects to the file system produced a similar problem. In addition,
cases were occuring with other providers where projects were being
incorrectly considered under version control.
To solve it, we required new support from the UI team for filtering. We
prototyped the work, and discussed with some repository providers whether
they agreed we needed to go forward and what the impact was. We also
changed our target managment providers to use the persistent property
scheme as a safer avenue for refining the support prior to moving the
This all took time. It was a difficult decision to make this change so
late, but our bug reports surrouding the issue clearly showed that this was
going to be an ongoing problem for all 2.0 based products for all
repository providers. This change could not occur in a 2.x Eclipse update,
so it was now or never.
The actual code changes and the mechanisms involved were relatively
straight forward. The changes have all been retested, and reviewed in part
or in whole by four developers. The CVS team has been running with these
changes for sometime. We couldn't commit the changes to the CVS provider
until now since that would've forced all users to migrate between F2 and
======== CVS users: Supporting teams with a mix of pre+post F3 builds
Q: Lets say I remove the nature and commit the .project, what happens if
others on my team take that change?
A: They should avoid updating the .project, or equivalently they should
avoid committing the modified .project.
If they do by accident, its easy to fix: just re-Share the project
(Team->Share Project->CVS). We will see the CVS info on disk and re-mark
the project in the workspace as a CVS project. All your synchronization
information will be there.
Q: What happens if I create a project in an F3+ build and someone on my
team with a pre-F3 2.0 build wants to use it?
A: No problem. When they checkout the project their .project will be
updated to include the CVS nature. Then you are in the same case as above.
Although you are not required to move to F3+, we encourage you to move at
your earliest convenience.
======== ======== ========
Please respond to the matching newsgroup post if there are further
questions or concerns,