"Martin Letenay" <mle@whitestein.com> wrote on 08/04/2005 04:42:14 AM:
> > Martin,
> > Excellent work. I had a quick look at your changes and they
> > looked really good. I will give your code a workout on the weekend
>
> Well, the changes might look good, but Mark already found 2 bugs there
...
>
> Anyway, these bugs pointed me to 2 questions, I'm not sure I have answer
> for.
>
> - when doing "svn status -u -v" subversion does really poor job for
incoming
> changes.
> There is no url, no lastChangedRevision/Date/Author, no nodeKind there
in
> the returned ISVNStatus.
>
> As one of my first pacthes for subversion, I've started to subsequently
call
> "svn info" to get the nodeKind on some resources.
> The question is, should we try to get as much info from svn when doing
> synchronize, and call svn info
> an all (incoming) resources ?
> The code might get a bit cleaner, but there's this obvious performance
cost.
> Is it worth it ?
> Don't you know, is this incomplete ISVNStatus a subversion feature, or
is it
> going to be solved in some future release of subversion?
I brought up this point back when you added that change to call svn info.
I guess it just wan't clicking with you that this information was missing.
Personally, I would like to see us at least try adding the call to svn
info. If performance is terrible then we can look for alternative ways to
handle this, but let's see how bad the problem is first. I would rather
pay a performance penalty for correctness.
We need to raise the ISVNStatus issue with Subversion and the JavaHL
maintainers. I seem to recall at one point someone saying this requires a
protocol change that would have to wait for 2.0. Daniel Rall suggested
that we add a text file to our repository that contains any issues like
this that we have with JavaHL. I think that Daniel also suggested that
the JavaHL svn info command could probably be modified to take an array of
URL's. This could potentially be faster.
> - the old SVNStatusSyncInfo#calculateKind() was using revision
comparator to
> compare lastChangedRevision of local and remote resource, to find out
> whether there is an incoming change.
> I think it is unnecessary, since we already have the text and prop
> statusKinds for both local and remote resources.
> Am I right or have I overlooked something ?
I do not know, I will have to defer to you on that.
Mark
_____________________________________________________________________________
Scanned for SoftLanding Systems, Inc. by IBM Email Security Management Services powered by MessageLabs.
_____________________________________________________________________________
Received on Thu Aug 4 22:32:47 2005