The syncronization support is NOT complete.
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
1. SVNSubscriber
This one calls SVNClient -r HEAD -R to get the whole remote tree
2. SVNWorkspaceSubscriber
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).
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.
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.
----- Original Message -----
From: "Aadi Deshpande" <mailinglists@clubmom-inc.com>
To: <dev@subclipse.tigris.org>
Sent: Thursday, August 05, 2004 6:30 PM
Subject: getting team synchronization to work?
> Hi,
>
> I was under the impression that Synchronize view was working ( from my
> last perusal of the mailing lists ) in HEAD for subclipse-3 so I got
> latest and tried to build it, with no success?
>
> Is Synchronize not ready for prime time, because I constantly got
> "Internal Error"s when I tried to either get latest or commit code,
> owing to an NPE in SVNRemoteTree.java code
>
> ( if this is my mistake somehow, please let me know, and you can stop
> reading here ).
>
> I spent some time trying to get it working, and it seems like a lot of
> the functionality is already there and probably needs cleaning up a bit
> and some changes to logic.
>
> So I was hoping to ask some questions here to see if someone could help
> me get it into a useable state.
>
> My first problem was that the logic in SVNRemoteTree.fetchVariant()
> method. The first problem ( at least for me ) was that it tried to
> build a RemoteFolderTree out of any given IResource, whether or not that
> resource was a SVNKind.FILE or SVNKind.DIR.
>
> That would eventually fail, because later on down the code, the
> memberVariant is only added to the resourceVariantMap if the entry is an
> SVNKind.DIR. So later on, when iterating through all the dir entries,
> you would get a NPE trying to get the resource back from the map, if you
> were updating only file.
>
> I refactored it, so that ( at least in my menial tests ), it does the
> 'right thing' based on what IResources were passed in.
>
>
>
> The second issue seems to be that the UpdateSynchronizeOperation seems
> to use the SVNOperations.getInstance().get() method, which seems to get
> the contents and set the contents in the actual resource, bypassing any
> update of the actual metadata updating. it also sets the resource to
> read-only so no further editing can occur. Why not use
> SVNTeamProvider's update in this case?
>
>
> My third issue is that once i've made the abovementioned changes, I'm
> able to update fine ( commit I will be working on afterwards ), but I
> cannot seen to update the tree view to reflect the changes made. The
> only way I have been able to do it is by getting out of the Sycnchronize
> view and refreshing it.
>
>
> Please let me know if I've been barking up the wrong tree(s) or if
> someone has a better handle on any/all of this than I do.
>
> I feel that subclipse has come a long way to being eminently useable,
> and this functionality would put it over the top for a lot of us, so
> anything else that I can do to help expedite the situation would be
> gladly taken care of.
>
> Thanks,
> -a
>
> p.s. is there an IRC channel where subclipse developers hang out? i was
> at one on freenode.net, but it seems to be inactive.
>
>
>
>
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@subclipse.tigris.org
> For additional commands, e-mail: dev-help@subclipse.tigris.org
>
Received on Fri Aug 6 09:02:32 2004