Panagiotis Korros wrote:
>The syncronization support is NOT complete.
Thanks for the clarification. It seems to be getting close. :-)
>Currently there are many things that can't be effeciently implemented due to
>the fact that the Javahl bindings are a work in progress and only cover a
>small subset of the svn API.
>Currently there are 2 implementation of the Subscriber
>This one calls SVNClient -r HEAD -R to get the whole remote tree
>This is the one currently enabled. Internally it uses 'svn status -u' to
>populate a tree of changes.
>This is prefered because 'svn status -u' is implemented very efficiently in
>the core subversion libraries.
>It has some drawbacks like, if a resource is added in the repository,
>subversion reports this file as of
>UKNOWN kind (neither a file nor a folder).
I'm still learning the Eclipse SDK and the Subclipse/JavaHL api, but is
it possible in such a case, to fallback to use SVNClient to retrieve
knowledge of those files that are represented as unknown?
>As I said before I think that the second approach is the way to go.
>Currently I am working on getting the SVNWorkspaceSubscriber to listen to
>resource changes and to update itself to reflect those changes.
>I will try to clean up this code and commit it so you can work on it.
Thank you. That would be very much appreciated. As I said before, it
seems like it's possible to get it to a much more useable state very
soon. The big stickler for me is that the tree view in the Sychronize
repository doesn't refresh, which seems like they would be benefited
from the changes you're implementing.
>The SVNSubscriber should be kept if we want to implement a 'Compare with
>revision/tag/branch' functionality. This kind of functionality can't be
>addresed with the use of a 'svn status -u' command.
>About the UpdateSynchronizeOperation, I think that these where copied from
>the filesystem example and they have to be adapted to svn.
That makes much more sense.
Thanks for the information,
Received on Sat Aug 7 00:49:25 2004