On Fri, 30 Sep 2005, Mark Phippard wrote:
> > Will the URL field ever be different between an out of date WC item, and
> > the URL field known to the repository?
>
> I do not see how they could be different in the current code, but perhaps
> in some future enhanced version of the move API they could be different?
I suppose...though I can't think of exactly how that would work. Possibly
something related to merge tracking? I'm going to remove the ood_url field
from the svn_wc_status2_t for now (it can always be added back in later if
we find it to be useful at some point in the future).
> > I totally agree that this is how a _client_ should work (including how
> > 'svn status --show-updates --verbose' should work, but doesn't), but am
> > somewhat leary of completely dropping the entries information from the
> > API.
>
> I raised some of these issues after Paul submitted the initial patch. What
> I kind of came around to is that the way Paul did it is probably best. It
> makes all of the info available in the API, and the client can decide what
> to do with it. Using Subclipse as an example, we have our own status
> object in svnClientAdapter. I will probably not change it at all, and
> instead just pick the right data out of the JavaHL status object.
We are in agreement that the info should be available via the C API. Since
JavaHL is also an API, I believe it should be available there as well.
> Given that URL's can be pretty big, I do think there is a decent reason to
> drop the extra one if we can.
I agree, based on our assumption that it currently never differs -- +1.
> > Why does 'svn status --show-updates --verbose' show information from the
> > entries file instead of the information it just pulled down from the
> > server?
> > Previously, it didn't retain enough of the info pulled down from the
> > server to be able to display it on stdout. Why was it written like that?
>
> I have not been around long enough to know, but I noticed that the status
> structure re-uses the WC entry structure. My "guess" is that when status
> was first written, it was purely a local operation, so it made some sense
> to reuse the WC entry structure. When the code was added to contact the
> server, the rest was "bolted on". One of the reasons Paul did his patch
> the way he did, was that when there is a new item in the repository, the WC
> entry structure is null because there is no local file. It started to seem
> fishy to us to perhaps suddenly "construct" one of these and then only fill
> in the handful of fields that applied to the server, even though that is
> what I instinctively wanted to do.
>
> I think if you were starting from zero today and writing this command, that
> the structure would probably be unique to the requirements and not reuse
> another structure. That being said, I do not think the way it is now is
> all that bad. It is certainly workable.
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 always wind up coming back to that the
> way Paul did this was probably the best way -- with the possible exception
> of the extra URL.
Yup.
> But, to get rid of that field in the C API, you have to
> be willing to construct a WC Entry structure that only has that one field
> populated, and that doesn't seem quite right either.
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 JavaDoc parameter names don't match the actual parameter names.
>
> I noticed those parms, but wasn't quite paying attention that the JavaDoc
> was describing them. Also, I was just trying to throw you a quick example
> to work from.
Sure, just reviewing it as we go.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Mon Oct 3 22:57:05 2005