| Team APIs: starting point for new provider / synchronizer [message #318926] |
Thu, 09 August 2007 06:45  |
Eclipse User |
|
|
|
Hi,
I am trying to integrate our versioning repository with Eclipse and I am not
too sure where to start. The Team docs mention that the approach to take
depends on whether "there is <an> existing infrastructure for maintaining
the synchronization state of the local workspace".
What I have is something similar to CVS, i.e. a local workspace with
metadata for each file that tells me what the base & remote revisions are -
does that qualify as an "infrastructure for maintaining the synchronization
state of the local workspace"?
I don't have any support for caching the result of synchronizing a resource
(i.e. the result of SyncInfo.getKind()), does this mean I should start from
the ThreeWayXxx hierarchy?
It seems to me that CVS doesn't have that capability either (i.e. the
metadata in the CVS subdir contains pointers to the base & remote versions,
but doesn't indicate whether a given file is Changed, Conflicts, ...) but
still the CVS Team implementation doesn't leverage the ThreeWayXxx classes -
is that for other reasons?
Any pointers welcome! Thanks,
Franck
|
|
|
| Re: Team APIs: starting point for new provider / synchronizer [message #318969 is a reply to message #318926] |
Thu, 09 August 2007 10:59  |
| Eclipse User |
|
|
|
Franck,
CVS doesn't use the ThreeWayXxx classes because CVS has it's own format
for persisting meta-data. However, many of the mechanisms used by the
the ThreeWayXxx API are used by CVS as well. If your repository uses a
similar means to persist it's metadata (i.e. CVS folders for CVS) and
you want to have compatibility with your repositories command line tools
then you would need to write something similar to CVS. However, if this
is not a requirement, then you could use the ThreeWayXxx classes.
You also should keep in mind that the CVS plug-in in Eclipse is what we
consider first class Eclipse integration. I know of other repository
providers that have gone for a lower level of integration by launching
existing executables from within Eclipse. This is really on an option
worth considering if you do not currently have any Java API for your
repository.
Hope this helps...
Michael
Franck wrote:
> Hi,
>
> I am trying to integrate our versioning repository with Eclipse and I am not
> too sure where to start. The Team docs mention that the approach to take
> depends on whether "there is <an> existing infrastructure for maintaining
> the synchronization state of the local workspace".
> What I have is something similar to CVS, i.e. a local workspace with
> metadata for each file that tells me what the base & remote revisions are -
> does that qualify as an "infrastructure for maintaining the synchronization
> state of the local workspace"?
> I don't have any support for caching the result of synchronizing a resource
> (i.e. the result of SyncInfo.getKind()), does this mean I should start from
> the ThreeWayXxx hierarchy?
> It seems to me that CVS doesn't have that capability either (i.e. the
> metadata in the CVS subdir contains pointers to the base & remote versions,
> but doesn't indicate whether a given file is Changed, Conflicts, ...) but
> still the CVS Team implementation doesn't leverage the ThreeWayXxx classes -
> is that for other reasons?
>
> Any pointers welcome! Thanks,
> Franck
>
>
|
|
|
| Re: Team APIs: starting point for new provider / synchronizer [message #319156 is a reply to message #318969] |
Tue, 14 August 2007 04:45 |
| Eclipse User |
|
|
|
Michael,
Thanks for your reply:
"Michael Valenta" <Michael_Valenta@ca.ibm.com> wrote in message
news:f9fa39$o68$1@build.eclipse.org...
> Franck,
>
> CVS doesn't use the ThreeWayXxx classes because CVS has it's own format
> for persisting meta-data. However, many of the mechanisms used by the the
> ThreeWayXxx API are used by CVS as well. If your repository uses a similar
> means to persist it's metadata (i.e. CVS folders for CVS) and you want to
> have compatibility with your repositories command line tools then you
> would need to write something similar to CVS.
Well, our repository has java APIs, which will maintain the metadata files
for me when invoked from the Team integration.
I have enough metadata to reconstruct the base & remote trees, however the
file status that comes out of a sync (locally modified, conflict, ...) is
not kept in the metadata (much like CVS).
I think my confusion comes from the terminology "sync bytes" and "sync
info". In some places those terms seem to denote the information needed to
uniquely identify a given variant (e.g. in ResourceVariantTree/ByteStore
javadocs), while in other places they denote the result of comparing a
resource with its remote (or base+remote for 3 way sync).
And from looking at the team.core package it looks like only the first kind
(bytes to identify a given variant) needs to be cached / made persistent,
while looking at the CVS implementation there is support to cache the result
of synchronizations (e.g. ccvs.core.resources.SyncInfoCache).
I am going to try and implement an AbstractResourceTree based on my
metadata, and a synchronizer that computes sync states on the fly, and I'll
see where this takes me...
Franck
|
|
|
Powered by
FUDForum. Page generated in 0.03170 seconds
Home