To understand the sync view code you should read the following links
to see how the eclipse sync support is working.
http://help.eclipse.org/help30/topic/org.eclipse.platform.doc.isv/guide/team_synchronize.htm
http://help.eclipse.org/help30/topic/org.eclipse.platform.doc.isv/guide/team_synchronize_beyond_basics.htm
Also the CVS plugin code and the org.eclipse.team.examples.filesystem
example were very helpfull to me.
The main parts of the sync view functionality in eclipse are the
Subscriber and the SubscriberParticipant. The Subscriber is
responsible for collecting the SyncInfo objects (core functionality)
and the SubscriberParticipant is responsible for displaying those
objects in the sync view (ui functionality).
There is an abandoned implementation in
org.tigris.subversion.subclipse.core.sync.notused.SVNSubscriber
that was using the org.eclipse.team.core.variants.ThreeWaySubscriber.
This implementation was fetching the base and remote trees to create
the SyncInfo objects.
It was abandonded mainly because it was trying to reimplement the 'svn
status -u' functionality. It was decided that 'svn status -u' does
this better and we switched to the SVNWorkspaceSubscriber
implementation.
The current subscriber implementation (SVNWorkspaceSubscriber) extends the
org.eclipse.team.core.subscribers.Subscriber class. It fetches the
remote resource statuses by executing an 'svn status -u' (see
SVNWorkspaceSubscriber.findChanges() method) and stores them into an
org.eclipse.team.core.variants.ResourceVariantByteStore object.
It also uses the StatusCache to get the local changes and
SVNStatusSyncInfo to compute the sync state from the local and remote
statuses.
The SVNWorkspaceSubscriber also listens to resource modifications to
automatically update the local status of the resources.
> We have been plugging away at adding actions, for the most part with
> success. The main problem is that the core Sync code just seems to have
> some problems. We think we have corrected a couple of these (and
> committed them) but it is hard to tell. Clearly, the Sync stuff operates
> on some kind of cache of information and it seems like the problem lies
> somewhere within that cache. When we started working on this, after you
> committed or updated items they never disappeared from the Sync view, even
> if you deleted it and ran the action again.
The sync view uses the SVNWorkspaceSubscriber.getInstance() method to
obtain the subscriber. There is only 1 instance and that's why the
sync view doesn't appear empty
when you run the action again.
> This seems to be corrected
> now. The main problems now seem to be with incoming additions/deletions.
> Generally, after you update these items they never go away. They always
> show as additions. Stepping through the code there is nothing obvious
> that is wrong, which tells me it is buried deep in the class hierarchy of
> the process.
This is because the ResourceVariantByteStore still contains the remote
changes. In the case of an update or commit the commited/updated
resources must be removed from the
ResourceVariantByteStore.
>
> Does anyone have any thoughts they can share on how the core Sync code
> should work or where it can be fixed? I would be very interested in what
> was tried in the past and what led the code to being what it is currently.
> It doesn't use some of the same provided "API" classes that CVS does. It
> would be tempting to just toss aside the code and try to rewrite it based
> on the current docs and API, but I just suspect the code is where it is
> for a good reason.
>
> I think if this "refresh" business could be sorted out it would advance
> the state of this action greatly. The majority of it works just fine, but
> I think this issue interjects a lot of perceived "flakiness" into the
> behavior. For example, sometimes when the view comes up the status
> indicators say there are 5 incoming changes, but I only see 2. If I click
> through the various Incoming/Outgoing modes, then all 5 items will show
> up. Stuff like that. I cannot help but think we are missing some
> critical pieces of "infrastructure" code that would magically make it all
> just work.
>
> Does anyone have any contacts with the Eclipse Team developers? I recall
> that they mentioned in the Subversion bugzilla entry that they might be
> willing to pitch-in at some point. Now would be a good time. I think we
> have advanced Subclipse to being very close to release quality. It would
> be nice if we could get some of this stuff sorted out and behind us.
>
This bugzilla entry is:
https://bugs.eclipse.org/bugs/show_bug.cgi?id=37154
> Thanks
>
> Mark
Mark thank you for all the good work, I hope that this email will help
you to make the sync view to finally work as expected.
Panagiotis
Received on Thu Jan 6 05:44:27 2005