On Fri, 05 Aug 2005, Mark Phippard wrote:
> This is something we critically need in Subclipse from JavaHL, but as I
> understand things the root of the problem is in the svn_client API. Let
> me step back and explain.
Mark, I may mis-understand here, or this may've been sent before all the
discussion on the dev@subversion list occurred, but I thought JavaHL was
simply failing to fully expose the APIs/info needed by Subclipse.
...
> If you look at the screenshot, it is ultimately just a graphical
> representation of the svn st -u command, which is essentially what drives
> this feature in Subclipse. We have worked hard over the course of the
> past year to get this feature working perfectly, but there have always
> been nagging problems here and there depending on the approach du jour. We
> have always known, or at least suspected, that the fundamental problem is
> that the JavaHL equivalent of svn st -u does not give us all of the
> information we require to implement this feature. Specifically, when it
> gives us the list of changed items from the server, it does not give us
> any information about the revision of the item on the server. We get back
> information about the local copy of the item (or no information at all if
> it is a new item). We really need the information of the item on the
> server, specifically the last changed revision and the URL, but ideally we
> would get other information such as whether it is a file or folder, the
> last author, date etc....
>
> We have had to resort to calling the JavaHL equivalent of svn info on each
> item we get back from the status call, one item at a time, to get things
> working correctly. Needless to say, the performance is not acceptable
> with this approach.
>
> I was discussing this on IRC with sussman and he seemed to think that the
> status process receives most, if not all, of this information from the
> server and currently just discards it. He suggested that the client API
> would need to be rev'd to return the additional information and that I
> should take this to the dev@ list for discussion. I am a Java programmer,
> so I cannot do this, but I have asked my co-worker Paul Burba, who has
> done the EBCDIC port, to take a look at the API's and see what he can
> figure out.
Mark, if this is only a JavaHL change, I'm willing to make the changes,
but would like you tell me what the expected Java API should look like.
If the svn_client API needs to be rev'd, it's probably more than I can
bite off at this time, but my offer to adjust JavaHL stands after the
svn_client API offers support for what Subclipse needs.
- Dan
Received on Thu Aug 11 06:39:55 2005