Panagiotis Korros <panagiotis.korros@gmail.com> wrote on 01/06/2005
04:20:04 AM:
> 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.
CVSWorkspaceSubscriber ultimately extends ResourceVariantTreeSubscriber
which is the high-level API I would like to pursue more in Subclipse.
> 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).
I realize that is what it is doing, and I want to continue doing it. What
I was acknowledging was that the high-level Subscriber implementations
make it difficult to use svn status -u. I was merely speculating on ways
we might be able to use the high-level API but still use svn status -u.
> If you look at the cvs code you will find that many CVS actions also
> interfere with the Subscriber.
Are you saying there are cases where the CVS Synch view exhibits some of
the same problems that we have?
> 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.
Thanks, this might be useful.
Mark
_____________________________________________________________________________
Scanned for SoftLanding Systems, Inc. by IBM Email Security Management Services powered by MessageLabs.
_____________________________________________________________________________
Received on Fri Jan 7 00:46:49 2005