Mark Phippard wrote:
> On 4/21/07, Hyrum K. Wright <hyrum_wright@mail.utexas.edu> wrote:
>> Mark Phippard wrote:
>> > On 4/20/07, Hyrum K. Wright <hyrum_wright@mail.utexas.edu> wrote:
>> >> -----BEGIN PGP SIGNED MESSAGE-----
>> >> Hash: SHA1
>> >>
>> >> The following patch updates the JavaHL list implementation to use the
>> >> most recent version of svn_client_list. The callback addition and
>> other
>> >> changes were straightforward, except for the implementation of the
>> >> compatibility wrapper.
>> >>
>> >> There was a semantic change between svn_client_ls3() and
>> >> svn_client_list() which accounted for in svn_client_ls3()'s
>> >> implementation of the wrapper. I believe that I've captured the same
>> >> changes in the MyListCallback class, but want to make sure.
>> >
>> > In the DirEntry class you change the constructor. You have to add a
>> > new one and leave the old one intact, else you are breaking
>> > compatibility.
>>
>> The DirEntry constructor is documented as only being used by the JNI
>> code. As such, I don't believe that it constitutes a public interface.
>
> Right. OK.
>
>> > The MyListCallback looks OK. I am just trusting that you are right
>> > about the semantic change since I have not looked at the C API. I am
>> > a little confused about what exactly the change was though.
>>
>> So was I, honestly. The biggest change that I noticed is that the
>> svn_client_list2() produces one more dirent than svn_client_ls3() if
>> called for a directory. The extra entry being for the directory the
>> list was performed on.
>>
>> The other issue is that if a list is performed on a file, it's name is
>> not included in the path that's returned. Perhaps someone more familiar
>> with the implementations can comment.
>
> So if the old C methods were modified to call this new function do
> they provide a similar workaround to maintain compatibility?
Yes. And the C wrappers were the basis for the code in the
MyListCallback wrapper.
Committed in r24712.
-Hyrum
Received on Mon Apr 23 18:56:15 2007