> 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 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.
Given that URL's can be pretty big, I do think there is a decent reason to
drop the extra one if we can.
> 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.
>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.
Getting back to the main issue, 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. 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.
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 Sat Oct 1 00:54:03 2005