Re: [platform-team-dev] old and new synchronization API

[Michael Valenta <Michael_Valenta@xxxxxxxxxx>]

Ingo,

Wow, you programmed against the old
"VCM" plug-ins and the code still works in 3.2? These plug-ins
haven't been part of the SDK since 1.0. Do you build them yourself or did
you just extract them from an Eclipse 1.x drop? I must say that I'm quite
fascinated with this. We've always strived to make Eclipse backwards compatible
but I would not have believed that the old 1.0 VCM plug-ins would still
work in 3.2.

Given that the plug-ins still work and
Eclipse is still committed to remain backwards compatible in the 3.x stream,
I would say there is a good chance that they will continue to work in the
3.x stream. However, work has begun in planning a 4.0 version. It is a
few years off but I doubt that the code would work in 4.0. At this point,
I'm not sure what the backwards compatible statement for 4.0 is so it is
possible that the 3.0 Synchronize framework may not be supported in 4.0
as-is either (although I'm pretty sure that steps would be taken make the
migration as easy as possible if the decision was made not to be backwards
compatible). Given that 4.0 is a ways off (i.e. we just started the planning),
I wouldn't really consider that in making any descisions.

As for stability, the 3.0 Synchronize
framework is stable and is actually not undergoing much change. The reason
is that, in 3.2, we introduced another type of Synchronization to support
the intergration of logical models into Team operations. I would say that
the model-based Synchronization is not quite as stable as the 3.0 style
Synchronization but has some additional features (here's a link to the
FAQ that describes the two Synchronization types: http://wiki.eclipse.org/index.php/CVS_FAQ#Synchronizing_has_some_regressions_in_Eclipse_3.2._Why.3F).

In regards to your question about generic
Team operations (i.e. like we had in 1.0), there is currently no plan to
provide such commands. The attempt to do so in 1.0 was actually a dismall
failure since most repositories are so different that coming up with a
standard set of commands was actually disabling for most repositories being
integrated with Eclipse. Repository vendors tend to be much happier with
providing their own operations. Therefore, the new Synchronization framework
has sevral levels of integration to support these differences.

As to whether you should move to the
"Team" plug-ins from the old "VCM" plug-ins, I can't
really answer that question for you. The disadvantage of upgrading is that
you would need to do more than a trivial amount of work. The advantage
of moving is that you will be using a more flexible framework that is being
actively maintained (i.e. there have been no changes made to the VCM plug-ins
since Eclipse became open source).

Hope this helpd,
Michael

"Jahnel, Ingo (Allianz Deutschland AG)" <ingo.jahnel@xxxxxxxxxx>
Sent by: platform-team-dev-bounces@xxxxxxxxxxx

05/04/2007 09:39 AM

Please respond to
Generic team support framework <platform-team-dev@xxxxxxxxxxx>

To	<platform-team-dev@xxxxxxxxxxx>
cc
Subject	[platform-team-dev] old and new synchronization API

Hi,
 
our self-developed team adaper is based on
the 'old' team plugin structure, i.e. the packages org.eclipse.vcm.core
and org.eclipse.vcm.ui. It still works perfectly with Eclipse 3.2, but
we wonder for how long in the future this will be the case. Currently we
are thinking about migrating our plugin onto the synchronization API which
is new since Eclipse 3.0. But we are not sure if it is the right time to
do this and if it is really necessary.
Could you please tell us how stable and mature the current status of the
API is? 
Concerning synchronization support it says
in the documentation that "the means of affecting the state is left
to the implementer". Are there plans to integrate this task into the
API? Which other tasks are planned to be integrated in the future and with
which version?
Will there be drawbacks when staying on the current status like that the
plugin will miss notifications about file changes? Will this get worse
with future releases of Eclipse?
 
Thanks
Ingo Jahnel
 _______________________________________________
platform-team-dev mailing list
platform-team-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/platform-team-dev