[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

RE: [Subclipse-dev] The Synchronize problem ....

From: Martin Letenay <mle_at_whitestein.com>
Date: 2005-08-05 16:18:19 CEST

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

This is an archived mail posted to the Subclipse Dev mailing list.