Daniel Rall <dlr@finemaltcoding.com> wrote on 10/04/2005 01:27:54 PM:
> On Tue, 04 Oct 2005, Peter N. Lundblad wrote:
> ...
> > > The problem with this approach is the scenario when the command is
showing
> > > you info about a new item in the repository. In that scenario the
> > > svn_wc_entry_t is currently null because there is no entry in the
WC. We
> > > did not feel comfortable changing this into a partially populated
> > > structure. This was also the main scenario where Subclipse
absolutely
> > > needs to get a URL and Node kind. That is why we needed the second
URL and
> > > kind fields. So, the only way the second URL can be removed is if
you are
> > > willing to have svn_wc_entry_t in the structure that only has the
URL
> > > populated (when it is a new file in the repository).
> >
> > Can't we just rename the URL field from ood_url to url and always
populate
> > it with the entries URL. We can share this data with the svn_wc_entry
if
> > it exists, so the cost is just an extra pointer in the
svn_wc_status2_t
> > struct.
>
> We could do this Peter, though it would slightly complicate the
> implementation in that the data for that field might come from the
> repository in the case of a new item having been added to the repository
> since the last update of the working copy (which is effectively an out
of
> date WC).
I do not know what the implications are (in terms of memory) for having
that extra URL in the C API. In the case of JavaHL, however, it would be
very simply to not add a second URL field to the Java class, and then
simply populate the existing URL field in the class with the URL from the
ood part of the structure when the other URL field is null.
Mark
_____________________________________________________________________________
Scanned for SoftLanding Systems, Inc. and SoftLanding Europe Plc 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 Tue Oct 4 19:39:25 2005