On Fri, 30 Sep 2005, Mark Phippard wrote:
> "Daniel L. Rall" <dlr@collab.net> wrote on 09/29/2005 07:17:17 PM:
...
> > - The new Status methods needs proper Java-esque names. Just prefixing
> > them with getOOD...() seems kinda vague (or something) for Java.
>
> I used your suggestion of "repos" instead of "OOD". The way the existing
> names in JavaHL are specified, I think they make more sense.
Given your suggestion below on how the API should work, I agree.
...
> > p.s. Anyone know off-hand if the JavaHL testing framework allows for
> > modification of the test repository without using the client library to
> > make a commit?
>
> You could do a couple of commits, and then use Switch to switch the WC
> back to revision 1. Then you could run status -u to bring in the server
> updates.
...
> > Couldn't the node kind field could actually differ, if an entry was
> > deleted and re-added as a different type (e.g. a file named "build" was
> > deleted and re-added as a directory).
>
> I suppose, but since there was only one Kind field already, we are already
> living with this. Given the way we use this, I am not sure it would pose
> too much problem.
I really think it should be possible to detect a change in an item's kind
by running status. That said, perhaps the API should look a lot different
(more on this below).
> How about URL? That one doesn't make sense to have a new field for. I
> think the rule should be if the URL field is going to be Null, and the
> oodURL is not null, then we should fill the existing URL field in with the
> oodURL so that there is always a URL. Currently, I think the only time
> you get a null URL (and kind) is when svn status finds a new item in the
> repository. I think it would be better to just have a single URL field. I
> think we could get away with a single kind field as well, but your point
> does raise an interesting scenario where having two fields might be
> better.
Will the URL field ever be different between an out of date WC item, and the
URL field known to the repository? If the URL field will never differ, I
think we should consider removing it from the C API as well as leaving it
out of the Java API, since it would be redundant.
I was wondering this while reviewing Paul's patch, but neglected to ask him
about it when we were discussing it on the phone.
> Finally, there is a part of me that thinks we shouldn't add any fields to
> the Java Status class. If the user specified to contact the server, then
> the 5 ood fields should just be mapped into the 5 existing fields. In my
> opinion, that is how it probably always should have worked, and is the
> more expected behavior. As long as the info is there, I can deal with it.
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.
Perhaps the Status API works as you suggest, but an Entry or LocalStatus
object available when called in a way which contacts the server for the most
recent status? I'm grasping -- let's focus on understanding the use case:
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?
...
> --- C:/workspaces/subclipse/JavaHL 1.2/src/org/tigris/subversion/javahl/Status.java (revision 16377)^M
> +++ C:/workspaces/subclipse/JavaHL 1.2/src/org/tigris/subversion/javahl/Status.java (working copy)^M
...
> @@ -171,6 +200,13 @@^M
> * @param lockCreationDate the date, the lock was created if any
> * @param reposLock the lock as stored in the repository if
> * any
> + * @param reposLastCmtRevision the youngest revision, if out of date
> + * @param reposLastCmtDate the last commit date, if out of date
> + * @param reposKind the kind of the youngest revision, if
> + * out of date
> + * @param reposURL the URL of the last commit, if out of date
> + * @param reposLastCmtAuthor the author of the last commit, if out of
> + * date
> */
> public Status(String path, String url, int nodeKind, long revision,
> long lastChangedRevision, long lastChangedDate,
> @@ -180,7 +216,9 @@^M
> String conflictNew, String conflictWorking,
> String urlCopiedFrom, long revisionCopiedFrom,
> boolean switched, String lockToken, String lockOwner,
> - String lockComment, long lockCreationDate, Lock reposLock)
> + String lockComment, long lockCreationDate, Lock reposLock,
> + long oodLastCmtRevision, long oodLastCmtDate,
> + int oodKind, String oodURL, String oodLastCmtAuthor)
> {
The JavaDoc parameter names don't match the actual parameter names.
---------------------------------------------------------------------
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:35:13 2005