[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [eclipse-dev] Team 2.0 CVS to go live in tomorrow's integration build (VCM 1.0 to be turned off)
|
As of Milesone 4, Team 2.0 CVS is now alive. A previous posting to
eclipse-dev, included below, describes how to use Team 2.0 as compared to
VCM 1.0. Here are a few additional points that may be helpful:
Outgoing Folder Deletions
Although Team 2.0 is mostly 1.0 feature complete, there are a few
exceptions. One is in how outgoing folder deletions are currently handled.
Because of how cvs meta-information is stored and used in Team 2.0 CVS,
outgoing folder deletions and their children will appear as incoming
additions in the sync view. This will be corrected by M5. In the meantime,
you can commit the incoming additions to the server as deletions by going
into the "Incoming/Outgoing Mode" of the sync view, and choosing "Override
and Commit" from the context menu of the incomming addition. (In this mode,
you can actually override either incomming or outgoing changes: one of the
many new features provided in Team 2.0;)
The .project File
New in M4 is the existance of the .project file within a project. The
.project file is generated by Core and contains the Eclipse specific
information about a project., which makes projects self-descriptive for
zipping as well. Because of the existance of the .project file, the
.vcm_meta file is longer required. If a project contains a .vcm_meta file
and a .project file, a task will appear in the task view indicating that
the .vcm_meta file can be deleted because it is no longer needed. This is
true UNLESS you are working with a team that is using both Team 2.0 and VCM
1.0. If you are in this situation, you should leave the .vcm_meta file in
the project until all your developers have switched to a post M4 Eclipse
build. Furthermore, you will need to keep the .vcm_meta file in the
repository up-to-date by releasing any changes to both the .project and
.vcm_meta file when the project description changes so that your pre-M4
developers will get these changes (If there is a .vcm_meta file in your
project, Team 2.0 will make sure it is up-to-date).
Binary to Text Conversion
Also new in M4 is a binary to text conversion tool for converting binary
files created using VCM 1.0 into text files when appropriate. However, this
tool has not undergone serious testing. Use it at your own risk. We will
send out notification when we are more confident in this tool. There is no
need to convert your files right away as the the Team 2.0 Sync view is VCM
1.0 friendly. However, you'll want to stay away from the Update command in
the Team context menu of resources until you have converted all your files
to the proper type (as mentioned below).
Happy CVSing,
The Team Team
Kevin_McGuire@oti.
com To: eclipse-dev@xxxxxxxxxxx
Sent by: cc:
eclipse-dev-admin@ Subject: [eclipse-dev] Team 2.0 CVS to go live in tomorrow's integration build
eclipse.org (VCM 1.0 to be turned off)
11/03/2002 07:10
PM
Please respond to
eclipse-dev
You've heard the rumours, you've seen the tease campaigns, now at long
last, the Team 2.0 CVS work is to go 'live' for Milestone 4. In
preparation, we will be 'turning on' the Team CVS plugins in tomorrow's
integration build and 'turning off' the VCM CVS plugins.
We've been busy rearchitecting the VCM->Team framework and subsequently
rearchitecting the Team CVS provider. As such, our primary goal has been
to at a minimum reestablish CVS 1.0 functionality. However, in Team 2.0
you will also see some long awaited features such as ability to mark
resources as text vs. binary, checking out projects that aren't at the
root, CVS automerge on update, etc. From here until we ship 2.0 we will be
refining workflow, working on performance, features, and of course bugs
fixes.
There are some things to note when moving over:
1. ***You should take a new workspace*** as part of swithing over. This is
because the way we store the synchronization information has changed, and
old sync info will be unrecoverable. Additionally you'd get annoying
errors on startup of the old workspace because the view IDs have changed
and open Team 1.0 views can't be reopened on startup.
If you really want to keep your old workspace because you want to preserve
your preferences, follow these steps:
- delete all your projects that are under CVS source control
- shutdown the workbench, take the new build,
- restart the workbench ignoring errors due to VCM 1.0 views no longer
being present
- open Perspective->Show View->Other->CVS->CVS Repositories
(a) create your repository location, find your projects, select them,
pick "Check out as Project"
or (b) in the CVS Repositories view menu (downfacing triangle), pick "Show
Modules", navigate to your module, "Checkout"
You *must* ensure that all your outgoing changes are either released,
discarded, or exported. We will no longer be able to resolve the changes
once you switch over due to sync info loss.
2. The VCM plugins are now turned off (the plugin files have been named
"plugin.xml.off"). They are still included in the builds to provide a
transition period for VCM 1.0 adapter implementers, timing to be decided.
3. Projects in the repository that are authored inTeam CVS 2.0 will be
compatible with VCM CVS 1.0 (and vise-versa). The project in the repository
looks identical.
4. We now use the correct CVS terms in our menus. This will throw you off
a bit at first, but its really the same stuff as before. Specifically, the
following table shows the VCM 1.0 and Team CVS 2.0 terms:
|----------------------------+--------------------------|
|VCM 1.0 |Team CVS 2.0 |
|----------------------------+--------------------------|
|Catch up |Update from Repository |
|----------------------------+--------------------------|
|Release |Commit |
|----------------------------+--------------------------|
|Version |Tag |
|----------------------------+--------------------------|
|Synchronize With Stream |Synchronize With |
| |Repository |
|----------------------------+--------------------------|
|Replace With Stream Contents|Replace With Latest |
|----------------------------+--------------------------|
|Replace With Version (file) |Replace With Revision |
|----------------------------+--------------------------|
|Add to Workspace (in Repo |Check Out As/Checkout as |
|explorer) |Project |
|----------------------------+--------------------------|
For new projects, the Team->Share menu item establishes the initial
association between the project and a provider (e.g. CVS).
5. The CVS Repositories view is found in Perspective -> Show View ->
Other->CVS. There is no Team perspective.
6. Our decorators are turned on via Window->Decorators->CVS. Decorator
support is global. CVS decorators update in a background thread because
they are expensive to compute: you may notice a delay and individual
decorator updating.
7. Performance is pretty good and we expect it to improve in the next
milestone rounds.
8. Our new CVS support can now properly deal with text vs. binary
resources, just like the CVS command line. However, existing resources
fetched from the repository will still be marked as binary. There is a
separate step which will need to occur to convert the projects in
dev.eclipse.org. We will provide a tool to help do this for Milestone 4.
Files marked as binary will work just like all files did in VCM 1.0, so not
converting over right away is no problem.
9. For binary/unconverted files, you should not use the "Update" command
from the Team menu. You should instead use the Synchronize View, as
before. "Update" merges in changes from the repository into your
workspace. If performed on a binary file, which all your files will be to
start, it will make a local copy of the retrieved file (renamed with a ".#"
at the front).
10. New files created will either be text or binary according to global
file name patterns. You will see a list of these patterns in the Team
preferences.
11. You will want to keep the CVS Console View open, which is found in
Perspective -> Show View -> Other->CVS. Information regarding the
execution of CVS commands goes there. This information is useful sometimes
when reporting a bug. If you're a CVS keener you will undoubtedly enjoy
watching it; for the others, tucking it away behind your Task View is more
likely.
12. In the CVS Repositories View, the modules are filtered from the view
menu (little dropdown triangle). Thus you can either browse by project or
browse by module. In the future we want to do something more clever with
presentation here.
13. In preparation for being CVS command line compatible, we now manifest
the CVS directory and meta files (Entries, etc.) in the project directory
tree. At the moment these can appear in the Navigator and Packages views.
We've included filters for these views to filter out CVS and *.CVS. This
is a temporary measure while Core provides us with support for properly
hiding the CVS meta information.
14. Note that since these directories and files contain CVS meta
information, you shouldn't move, rename, delete, or edit them, since this
is where we retrieve and store all the synchronization information for
which file revisions you have in your workspace. We plan to support
move/rename/delete of source controlled resources in the near future.
15. We have not yet worked out all the workflows for people using the CVS
command line against a live Workbench controlling the same resources. In
particular, we do not yet have the support for refreshing our cach'ed sync
information. We therefore recommend that people not use CVS command line
client against a live Workbench.
16. For those who need to re-enable VCM 1.0 for migration sake, they can do
so by renaming the 6 plugin.xml.off's to plugin.xml. Both Team 2.0 and VCM
1.0 can coexist in the same workspace, although with confusion since you
will have two Team menus, etc. A project can either be under VCM 1.0
control or Team 2.0 control, not both at the same time. The 6 plugins are
org.eclipse.vcm.core
org.eclipse.vcm.core.cvs
org.eclipse.vcm.core.cvs.ssh
org.eclipse.vcm.core.cvs.ext
org.eclipse.vcm.ui
org.eclipse.vcm.ui.cvs
As always, the platform-vcm-dev@xxxxxxxxxxx mail list will keep you in the
loop and is a good forum for your comments.
Cheers,
The Team Team
_______________________________________________
eclipse-dev mailing list
eclipse-dev@xxxxxxxxxxx
http://dev.eclipse.org/mailman/listinfo/eclipse-dev
