[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [platform-vcm-dev] Team Support - TO DO LIST
|
Jean-Michel,
Here are some comments.
> 3. The current default actions (used by the examples) default to depth
INFINITE on all operations. There should be seperate actions or a dialog to
prompt the user.
Another thought that James and I discussed last week is the ability to have
logical objects that have a depth that is different then the physical
object on which it is based. For example, directories have an infinite
depth whereas packages in java should have a depth of one. I suspect this
would need core support for specify the logical attributes (i.e. depth) of
the resource.
The CVS list looks good although I suspect we'll identify more things we'd
like as we start using it. Here is the status of what we've been working
on.
> History viewer (multi-line)
Released and works but will be improved shortly
> Create patch support
Released
> Full modules?
Next step
"Jean-Michel
Lemieux/OTT/OTI" To: platform-vcm-dev@xxxxxxxxxxx
<Jean-Michel_Lemieux@oti cc:
.com> Subject: [platform-vcm-dev] Team Support - TO DO LIST
Sent by:
platform-vcm-dev-admin@e
clipse.org
23/11/2001 02:07 PM
Please respond to
platform-vcm-dev
Hi Team^2,
It would be great if the Team Support community could put together a small
plan to outline our work items for the next couple of months. My hope is
that this will provide the Team Support (a.k.a VCM) community with an idea
of the dependencies and chronological ordering of the work items. For some
of the big work items, I would expect that a proposal/outline of the work
would be posted. A proposal/outline can be as simple as a couple of
use-cases that demonstrates the feature.
What'ya think?
Here is the first try, I can merge comments and post a completed version to
our web site next week.
-- jean-michel
============================================================================================
Team Core:
==========
1. Add synchronization APIs to core.
This inclues methods for local state queries and chache refreshed
(isCheckedOut, hasRemote), APIs for remote browsing, and algorithms for
determining the relative synchronization of a resource using a local, base,
and remote states. These APIs will support the interesting UI components
that we want to build (e.g. sync view, generic-decorators, and remote
browsing). A proposal for this API will be posted soon.
2. ValidateSave
This will allow a Team provider to perform a checkout _before_ the core
resources plug-in tries to set contents of a resource. ValidateSave support
will allow plug-ins such as jdt to perform programmatic resource
modifications (e.g. refactoring) and coexist nicely with a pessimistic Team
provider. A proposal for this API will be posted soon. (dependency on Core
Resources)
3. ValidateEdit
This will allow a UI component, mostly for editors, to include a Team
provider in the decision of whether a file can be edited or not. The Team
UI will implement an extension point in the Workbench called validateEdit
and can perform Team related prompts and operations to allow a file to be
edited. A proposal for this API will be posted soon. (dependency on
Workbench)
4. Transient resources
How to handle resources that the user or a plugin has defined as transient
(e.g. should not be shared with a team).
5. Project descriptions
Persisting project descriptions.
Team UI:
========
1. Synchronization viewer. This work will proceed in stages with the first
objective to have sync view with similar functionality as in R1.0. In
parallel with the sync view work we will be providing feedback to the
compare component. As the compare component changes the sync view will
incrementally catch-up to the changes.
2. Generic decorators will be developed as soon UI releases the decorator
support. (dependency on UI)
3. The current default actions (used by the examples) default to depth
INFINITE on all operations. There should be seperate actions or a dialog to
prompt the user.
4. Integrate with project natures UI support (dependency on UI)
Examples:
=========
The examples will continue to evolve. As new APIs are introduced the
examples will provide an easy way of creating a reference implementation
that can help validate the Team APIs.
CVS:
====
The focus here will be to self-host using this provider as of today. This
means that features and bugs that affect self-hosting will have a
high-priority.
History viewer (multi-line)
Create patch support
UI for picking file type for CVS add
Incrementaly improve repo browser
Sync view
Advanced versus basic CVS mode
Branch support (we need much improvement here, our R1.0 workflows we
extremely un-intuitive)
Full modules?
SSH2 support in extssh?
Merging a branch into the workspace (hopefully using the sync view and the
sync API)
Watch/edit
