Re: [platform-vcm-dev] Team Support - TO DO LIST

["Tim Ellison" <Tim_Ellison@xxxxxxxxxx>]

Jean-Michel Lemieux wrote:
>
> 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?

I agree that such a plan would be good, hopefully we can get it up on the
team web page once you have received the comments back.

> Here is the first try, I can merge comments and post a completed version
to our web site next week.

As a general comment.  It seems that we have maybe three or four people who
have already declared an interest in writing a provider (beyond the current
committers), so I would encourage any plan to be sympathetic to these
folks.  That means getting our APIs stable and correct is of prime
importance since it allows the work to proceed in parallel that much
sooner.

We (i.e., "the list") should agree on the first round of APIs starting from
the V2.0 code recently released, then press ahead with the self-hosting to
ensure we have a good and sufficient design.  We should also favor the
generic UI over others since that will exercise the intersection of the
future provider's implementations.  In each case I would prefer to see a
'compelling' use case as justification for API changes over technical
excellence.

That said, I'm unsure whether you wrote these tasks in priority order, but
if so I would rearrange them slightly to fit in with the above criteria.

>
============================================================================================

>
> 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.

Agreed.  Rather than waiting for an API to be posted, this can be designed
and agreed by the list.
High priority.

> 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)

Agreed, this and the next point are probably bounded by changes requested
of other teams.
I'd put this as a relatively lower priority (but we may as well get our
requests in now).

> 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)

Agreed.

> 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).

Agreed.  This may be quite provider specific, and again it would not be a
top priority on my list.

> 5. Project descriptions
>
> Persisting project descriptions.

Eh?<g>

> 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.

Yup, good way to drive the API.

> 2. Generic decorators will be developed as soon UI releases the decorator
support.
> (dependency on UI)

Ditto.

> 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.

We need those use cases for when it makes sense to do depth 0, 1, infinite
operations and I think (hope) that will lead us to the correct way to
present that to the user.

> 4. Integrate with project natures UI support (dependency on UI)

Definitely -- quite a high priority.

> 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.

Yes.  People who are ready to code now will be coming along with us for the
ride, so examples may not be immediately useful to them, however, I agree
that they provide another validation of the API and will be a useful legacy
for the next wave of provider writers.

> 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.

Yes, and we can argue about the order of this list to achieve your stated
goal.

>  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

Regards,
Tim