>
> I think it is worth trying. I would be willing to sacrifice
> some speed for correctness.
>
> I would have tried calling svn info for this. It seems like
> in the case where there are not a lot of incoming changes it
> would be faster than using svn ls. But it is just a guess.
>
> Mark
Well,
I believe the last (known (to me)) glitch in the synchronization view is
fixed.
To get the missing nodeKind info on incoming resources, the "svn info URL"
is now invoked after status call,
and proper resource handles are created ...
I had to add "ISVNInfo getInfo(SVNUrl url)" into ISVNClientAdapter, since it
only contained the File argument version.
(And to get info for resources not yet in working copy you have to use the
URL version).
Javahl and commandline adapter are implementing it, JavaSVN not yet.
(Since the info method is not present in any released version of JavaSVN
yet, just their trunk)
There is also new testGetUrlFromLocalFileName() in SVNUrlUtils (+ its unit
test).
In core I've created a new "StatusAndInfoCommand" which does the actual
information retrieval.
And I also did some small cleanup in SVNWorkspaceSubscriber (like moved
StatusInfo into SVNStatusSyncInfo as static innerclass).
Regards,
Martin
P.S.
I think by these fixes we can consider bugs #221, #226, #288 and #279 as
solved.
It also might have positive influence on problems mentioned in bug 165 and
maybe also 110.
Received on Fri Jun 17 20:55:10 2005