Daniel Rall <email@example.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
> > > 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
> > > kind fields. So, the only way the second URL can be removed is if
> > > 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: firstname.lastname@example.org
For additional commands, e-mail: email@example.com
Received on Tue Oct 4 19:39:25 2005