Daniel Rall <dlr@finemaltcoding.com> wrote on 08/10/2005 04:39:55 PM:
> 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.
My initial thought/hope was that the client API had the info that was
needed and JavaHL just needed to be revved to pass it back. I thought
that svn st -u -v was showing the revision of the item in the repository.
Sussman pointed out to me on IRC that this is not the case. We are
currently working on a design proposal for revving the client API to
include information about the repository item in the information it
returns. We are just trying to wrap our heads around it right now.
> 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.
I think you offered at one time to take a look at creating a JavaHL API
for svn info that would take an array of URL's. If this was something
that could be done (where it was not just hiding a series of roundtrips)
then that could be useful as a stop gap until the status API is changed.
Do you know if the client API for info of a URL could take an array of
items?
Mark
_____________________________________________________________________________
Scanned for SoftLanding Systems, Inc. by IBM Email Security Management Services powered by MessageLabs.
_____________________________________________________________________________
Received on Thu Aug 11 10:30:22 2005