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.
Eclipse has a feature called the Synchronize view that all Eclipse SCM
plugins are encouraged to support, and which Eclipse users pretty much
demand you support. You can see a screenshot of this feature on this
page:
http://subclipse.tigris.org/screenshots.html
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.
While he is doing that, I thought I would get the ball rolling and post
this to the list to see if anyone had any thoughts, objections, guidance
etc. on how to approach this.
We will continue to look for ways to work around this problem in
Subclipse, but ultimately this feature would work a lot better if this
additional information was provided to us when we ran these API's.
Thanks
Mark
_____________________________________________________________________________
Scanned for SoftLanding Systems, Inc. by IBM Email Security Management Services powered by MessageLabs.
_____________________________________________________________________________
Received on Sat Aug 6 01:39:36 2005