Daniel Rall <dlr@finemaltcoding.com> wrote on 08/25/2005 06:43:03 PM:
> > Perhaps the answer is to just modify the struct the way that Paul's
patch
> > does and just address this within JavaHL? In other words, the JavaHL
> > Status class would not change to have the new fields. Instead, the
> > SVNClient.cpp native code would just populate the fields in that class
the
> > way that I have described (when contactServer is true). Of course, we
> > could also potentially change the CLI when the -v option is specified
to
> > use the new struct fields for the output, if it is agreed that it is
> > desirable.
> >
> > I still think the URL and node kind fields ought to just always be
> > populated. It seems like a waste of memory to duplicate them when
they
> > will never be different. The issue for us in JavaHL is that when
there is
> > a new file in the repository these fields are currently always null,
and
> > we really need a value for those fields in that scenario.
>
> Assuming a change along these lines is the appropriate way to go, why
not
> make it to the core SVN libraries rather than to just the JavaHL
bindings?
> Subclipse can't be the only GUI to find this information useful -- this
does
> not strike me as an isolated use case.
Since you had some objections to my more radical ideas, I thought I was
suggesting we just stick with the approach in Paul's patch which is to
make both sets of info available in the SVN libraries. This would provide
maximum choice for any client as all info is available. I was merely
stating that I do not think we need both sets of info in JavaHL and could
possibly just change the code so that the info is coming from the new
struct fields (when the server is being contacted).
Part of the problem is that I am "thinking in Java" when I think about
this. Paul explained to me that the SVN Library struct is really made up
on a WC entries struct and then some extra status info. Which is probably
why the struct is null if the file only exists in the repos. I think of
this in terms of the Java status class, and see some of the fields like
URL and Node kind as being valid regardless of the type of change.
The way Paul did it seems fine and doesn't alter any of the behavior of
the way this already works. I leave it up to you who work in the C world
to decide if having the same field in the struct in two places makes sense
or not. However, if svn status is telling me about a new file in the
repository, I need to know what the URL and node kind are. If that means
new fields fine. If it means creating a partial entries struct that is
fine too. Just get the info available to me in Java.
Mark
_____________________________________________________________________________
Scanned for SoftLanding Systems, Inc. by IBM Email Security Management Services powered by MessageLabs.
_____________________________________________________________________________
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Fri Aug 26 02:52:32 2005