Re: svn commit: r1399064 - in /subversion/trunk/subversion/bindings/javahl: native/ src/org/apache/subversion/javahl/

[Mark Phippard <ma...@gmail.com>]

> 
> On Oct 16, 2012, at 9:25 PM, "Hyrum Wright" <hw...@apache.org> wrote:
> 
>> On Tue, Oct 16, 2012 at 9:19 PM,  <hw...@apache.org> wrote:
>>> Author: hwright
>>> Date: Wed Oct 17 01:19:21 2012
>>> New Revision: 1399064
>>> 
>>> URL: http://svn.apache.org/viewvc?rev=1399064&view=rev
>>> Log:
>>> JavaHL: Punch additional changelist parameter for property fetching to
>>> the Java layer.
>>> 
>>> [ in subversion/bindings/javahl/ ]
>>> * native/SVNClient.cpp,
>>>  native/SVNClient.h
>>>  (SVNClient::propertyGet): Add changelists param.
>>> 
>>> * native/org_apache_subversion_javahl_SVNClient.cpp
>>>  (Java_org_apache_subversion_javahl_SVNClient_propertyGet):
>>>    Add changelists param, pass to C++ layer.
>>> 
>>> * src/org/apache/subversion/javahl/ISVNClient.java,
>>>  src/org/apache/subversion/javahl/SVNClient.java
>>>  (propertyGet): Add overload to accept changelists param.
>> 
>> Mark,
>> This revision doesn't provide a way to return the inherited props,
>> which the underlying API does.  Right now the obvious method is a new
>> return object which contains both the property and any inherited
>> props, but I'd hate to create an object with just two fields.  Any
>> other suggestions?


How about returning a Map where the path is key?

Mark

Re: svn commit: r1399064 - in /subversion/trunk/subversion/bindings/javahl: native/ src/org/apache/subversion/javahl/

[Mark Phippard <ma...@gmail.com>]

On Tue, Oct 16, 2012 at 9:44 PM, Hyrum K Wright <hy...@hyrumwright.org> wrote:

> Well, we have to return both the existing property *and* the inherited
> props.  I don't think a Map will meet those criteria.

I thought the API just returns all the props and it is up to the
caller to decide what to do with the info, such as using the closest
value, merging them etc.  So why couldn't you return a Map where the
key is the path where the property was found, and the value is the
property value or even the Property object if we want to return the
key and value?

In Subclipse, I would probably use this for the bugtraq properties.
Currently, we walk the tree in the WC looking for the property.  I
would expect to be able to just call the API for a path in the WC.  I
will then get back anywhere on that path or any of its parents where
this property is set.  In my case, I would use the closest value to
the path I specified when I called the API.

-- 
Thanks

Mark Phippard
http://markphip.blogspot.com/

Re: svn commit: r1399064 - in /subversion/trunk/subversion/bindings/javahl: native/ src/org/apache/subversion/javahl/

[Hyrum K Wright <hy...@hyrumwright.org>]

On Tue, Oct 16, 2012 at 9:36 PM, Mark Phippard <ma...@gmail.com> wrote:
>>
>> On Oct 16, 2012, at 9:25 PM, "Hyrum Wright" <hw...@apache.org> wrote:
>>
>>> On Tue, Oct 16, 2012 at 9:19 PM,  <hw...@apache.org> wrote:
>>>> Author: hwright
>>>> Date: Wed Oct 17 01:19:21 2012
>>>> New Revision: 1399064
>>>>
>>>> URL: http://svn.apache.org/viewvc?rev=1399064&view=rev
>>>> Log:
>>>> JavaHL: Punch additional changelist parameter for property fetching to
>>>> the Java layer.
>>>>
>>>> [ in subversion/bindings/javahl/ ]
>>>> * native/SVNClient.cpp,
>>>>  native/SVNClient.h
>>>>  (SVNClient::propertyGet): Add changelists param.
>>>>
>>>> * native/org_apache_subversion_javahl_SVNClient.cpp
>>>>  (Java_org_apache_subversion_javahl_SVNClient_propertyGet):
>>>>    Add changelists param, pass to C++ layer.
>>>>
>>>> * src/org/apache/subversion/javahl/ISVNClient.java,
>>>>  src/org/apache/subversion/javahl/SVNClient.java
>>>>  (propertyGet): Add overload to accept changelists param.
>>>
>>> Mark,
>>> This revision doesn't provide a way to return the inherited props,
>>> which the underlying API does.  Right now the obvious method is a new
>>> return object which contains both the property and any inherited
>>> props, but I'd hate to create an object with just two fields.  Any
>>> other suggestions?
>
>
> How about returning a Map where the path is key?

Well, we have to return both the existing property *and* the inherited
props.  I don't think a Map will meet those criteria.

-Hyrum