[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: Daniel Rall <dlr_at_finemaltcoding.com>
Date: 2005-10-04 00:31:45 CEST

On Mon, 03 Oct 2005, Mark Phippard wrote:

> > It seemed as simple as removing it from svn_wc_status2_t. As it's
> already
> > present in svn_wc_entry_t (which svn_wc_status2_t includes as "entry"),
> > you'll always have the information available after filling in the
> > information for either type.
> 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).
Duh, of course! Thanks Mark.

> > Given that we believe that both sets of information -- WC plus repos --
> > should be available from the API, and we have some wiggle room still with
> > JavaHL, what would you think a modified JavaHL API which can provide both
> > WC and repos info in a single call should look like?
> I think the basic approach you were taking is fine.

Okay. It felt a little awkward to have no separation in the Status class
between the WC and repos-supplied information; some of the properties are
so close in naming that I was wondering if the same WC vs. repos separation
which is provided by the svn_wc_entry_t and ood_* fields on the
svn_wc_status2_t shouldn't exist in the Status API as well. For instance,
add a ReposStatus or Entry inner class; _something_ to help differentiate
similarly-named fields between the repository and working copy.

- Dan

To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Tue Oct 4 00:30:57 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.