> > 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.
>
> Yes, that is what I was getting at. I could tell looking at the Sync API
> that it would be potentially less efficient that using svn status -u. The
> tradeoff is that it greatly complicates the "infrastructure" code we have
> to write because we cannot re-use as much of the API. Did you consider
> using the API but trying to "trick it" on the back end?
I think that we can either reuse the 'svn status -u' functionality or
the eclipse high level support for synchronization. I choose the first
because I think that this is implemented very efficiently in
subversion and also I think that the sync view should have the exact
same output as the 'svn status -u' command.
Also notice that the CVS Subsriber doesn't inherit from a high level subscriber.
> In other words,
> perhaps the first request for either the local or remote changes could run
> svn status -u and store the results away, and when it comes back a second
> time to ask for the next set of changes, we could pull the results from
> the previous fetch?
> What I am looking for is whether you considered this and I might be
> wasting my time in pursuing it. I agree that we only want to run svn
> status one time if possible.
>
That is exactly what the code is doing. The repository (svn status -u
command) is contacted only once when the user initiates the sync view
and the refresh method is called as the spec describes:
"Server round trips should only occur within the refresh method of the
subscriber." (Subscriber java doc).
> > 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.
>
> Ick. I was hoping not to hear that. What are the other ramifications of
> this? If I have run a Sync action, but then go back to say the Java
> perspective and do some stuff, does that mean all of our SVN actions need
> to be doing something? Not even just the ones from the Synch view?
> Shouldn't something/somewhere just be using a resource change listener to
> capture activity and update itself as needed? Do you think we might get
> more of this for free if we are using the API at a higher level, such as
> ThreeWaySubscriber?
>
If you look at the cvs code you will find that many CVS actions also
interfere with the Subscriber.
I guess that the best solution should be to check if the local
resource revision number is greater or equal to the server revision
number in SVNStatusSyncInfo.calculateKind and report an
SyncInfo.IN_SYNC for those resources.
Received on Thu Jan 6 20:20:04 2005