Re: [PATCH] Was: Enhancement needed in svn status -u

"Daniel L. Rall" <dlr@collab.net> wrote on 09/29/2005 07:17:17 PM:

> Committed with a few formatting adjustments in r16344.

Thanks.

> I have written code to expose this additional status information via the
> JavaHL bindings (org.tigris.subversion.javahl.Status), and am in the
process
> of figuring out how to add a unit test for that to
> BasicTests.testBasicStatus(). I've attached the code -- it passes all
> existing tests. A couple problems with it:
>
> - 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. I also
corrected your JavaDoc to say for example that a value is Null when it is
NOT out of date.

> - I changed the existing constructor of the Status class in a
non-backwards
> compatible manner. Given that its JavaDoc is explicit that the ctor
> should only be called from the JNI bindings, and the version bump, I
think
> this may be okay. The alternative is to overload the ctor, leaving
the
> old one around, but marked as @deprecated.

I think it will be OK to just change the constructor.

> 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.

I have attached my patch.

> 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.

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.

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.

Thanks

_____________________________________________________________________________
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