[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: 'svn status -u -v', behavior and APIs

From: Mark Phippard <MarkP_at_softlanding.com>
Date: 2005-10-04 19:37:10 CEST

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
> > > 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
> > > 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
> > > 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
> > it with the entries URL. We can share this data with the svn_wc_entry
> > it exists, so the cost is just an extra pointer in the
> > 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
> 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.


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

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.