"Martin Letenay" <mle@whitestein.com> wrote on 08/05/2005 10:18:19 AM:
> 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 ...
I originally thought that the information returned was something like
lastRevision -1 and URL of null. I now see that is only on new items. So
I was thinking we could just check for a revision of -1 and only do the
info call then.
If JavaSVN has a way of making status work correctly, then we should move
this problem into the svnClientAdapter. Let it do the svn info calls
internally so that it gives back correct status objects. That way, there
is room for the JavaSVN adapter to just give back the right information
and not do this extra step. Of course we should wait to do this until we
have no other recourse.
Mark
_____________________________________________________________________________
Scanned for SoftLanding Systems, Inc. by IBM Email Security Management Services powered by MessageLabs.
_____________________________________________________________________________
Received on Sat Aug 6 00:23:01 2005