|
----- Original Message -----
Sent: Tuesday, February 24, 2004 7:16
PM
Subject: RE: [platform-team-dev] Fw: Team
API Usage Question
We are targetting the
integration build next Tuesday. If you can't wait, here is a link to a
previous message which describes the API a bit and has an attached project set
that can be used to load the API from the branch in which it now
resides.
http://dev.eclipse.org/mhonarc/lists/platform-team-dev/msg00019.html
"Paul Wuethrich" <paul.wuethrich@xxxxxxxxxxx>
Sent by:
platform-team-dev-admin@xxxxxxxxxxx
24/02/2004 12:26 PM
|
Please respond
to
platform-team-dev |
|
|
To
| <platform-team-dev@xxxxxxxxxxx>
|
|
cc
|
|
|
Subject
| RE:
[platform-team-dev] Fw: Team API Usage
Question |
|
When will the new synchronization API be
available?
-----Original Message-----
From: Michael Valenta
[mailto:Michael_Valenta@xxxxxxxxxx]
Sent: Friday, February 20, 2004
2:45 PM
To: platform-team-dev@xxxxxxxxxxx
Subject: Re:
[platform-team-dev] Fw: Team API Usage Question
It really boils down to whether there is value-add from using the
Eclipse Team infrastructure and whether it fits into your application. A new
synchronization API will be released shortly that provides a framework for
managing the sychronization state between the local workspace and a remote
location. If this is something your application requires, then it may be worth
investigating it. However, if all you need is simple puch/pull capabilities,
you're probably better off providing a small client that provides specifically
what you need.
"Paul Wuethrich"
<paul.wuethrich@xxxxxxxxxxx>
Sent by:
platform-team-dev-admin@xxxxxxxxxxx
20/02/2004 04:34 PM
|
Please respond
to
platform-team-dev |
|
|
To
| <platform-team-dev@xxxxxxxxxxx>
|
|
cc
| <Michael_Valenta@xxxxxxx>
|
|
Subject
| [platform-team-dev]
Fw: Team API Usage Question |
|
Per Michael's suggestion below, I'm continuing the
discussion.
The 3rd party requirements are virtually non-existent in
this case and
the repository provider will be our own customized interface
to an
rdbms. I'm guessing this doesn't change the suggested approach
of
building it from scratch?
"Michael Valenta"
<Michael_Valenta@xxxxxxx> wrote in
message
news:<40367918.3080005@xxxxxxx>...
> Paul,
>
> The Team plugin (org.eclipse.team.core) is dependant on the
resources
> plugin (org.eclipse.core.resources) so any RCP app that used
team
would
> need to be IResource based at least for the resources
under version
> control. Including the UI portion has further
dependencies (i.e. you'd
> end up with most of the platform SDK
plugins).
>
> Also, there is no Team API that allows third party
tools to invoke
> repository funtionality. The API is really there to
provide
integration
> points for repository providers. If you plan
on using a particular
> repository type (e.g. CVS) you may want to
investigate developing a
> small client that does only what you
need.
>
> If you want to discuss this further, the
platform-team-dev mailing
> list
> may be a better place.
>
> Michael
>
> Paul Wuethrich wrote:
>
> >
The requirements are to provide team-like functionality to an RCP
>
> application for version control over a small set of domain specific
> > files. The end-users will be "business" users and so a full
blown
> > CVS implementation is not required.
> >
>
> The current plan is to extend the Team api. Is there any reason
NOT
> > to use the Team plugins and build the versioning
functionality from
> > the ground up? I'm guessing not but I have
limited experience in
> > this area and have used the CVS client and
experimented with the
> > file system example.
> >
>
>
> >
>
_______________________________________________
platform-team-dev
mailing
list
platform-team-dev@xxxxxxxxxxx
http://dev.eclipse.org/mailman/listinfo/platform-team-dev
|
