Mark,
> Correct me if I have stated this incorrectly. The problem we
> are dealing with now is that when we run the JavaHL command
> to fetch the statuses (the equivalent of svn status -u) we
> get back all of the incoming changes, but the status
> information we get back does not include stuff like the
> remote revision number and URL that we need for the Synch
> view. So we have to then call svn info on each item to
> retrieve this? Over WebDAV, each svn info call is probably 5
> or more server roundtrips, so this is a huge performance
> killer but we need it for correctness?
Yes, that's the conclusion I came to.
> Perhaps if we changed out getAll boolean from false to true,
> we would then get this information on the JavaHL call?
> Performance wise, this would be a lot better than calling svn
> info although we will obviously get back more information
> than we need.
I'm not sure, but I think I've tried it and it returned exactly the same
statuses.
But maybe I'm wrong, I have to check it ...
> Finally, when I was debugging this, I noticed that svn status
> is run twice when I do a Synch. One time with contactServer
> = false, then again with true. Shouldn't it only do the
> latter? On Windows, svn status is slow.
That's quite probably not intentional, I'll take a look ...
> PS - One other thought if we cannot figure this out. Could
> we change our code so that we only call svn info when the
> information we need is missing? That way, if JavaHL is
> changed, or if say JavaSVN is able to fix this right away,
> then we could get a performance boost without changing our code.
Well, the problem is that we need that information always.
Originally, I was calling the info only for resources where I could not
determine the nodeKind.
However after the last BaseResource refactoring, I've realized that we need
the correct lastChangedRevision for comparing contents between local/base
and remote resource.
I'm not sure, but I think the refactoring did not broke it, I think it was
broken before,
it just sometimes worked due to other bugs with possitive side-effects.
Anyway, if we're not able to solve this properly, I was already thinking
about some workarounds in the
BaseResources, I believe I can make it work more-or-less correctly ...
Of course, I'd prefer the real solution ...
Martin
Received on Sat Aug 6 00:18:19 2005