On Tue, Jun 26, 2012 at 7:10 PM, Vladimir Berezniker <vmpn_at_hitechman.com> wrote:
> On Tue, Jun 26, 2012 at 3:17 PM, Hyrum K Wright
> <hyrum.wright_at_wandisco.com> wrote:
>> On Sun, Jun 24, 2012 at 6:09 PM, Vladimir Berezniker <vmpn_at_hitechman.com> wrote:
>>> Hi All,
>>>
>>> I have been taking a peek at ev2 code to see what it would take for JavaHL
>>> implementation and I have following questions that do not seem do be covered
>>> by the docs:
>>>
>>> * svn_ra__get_commit_ev2() takes svn_cancel_func_t as a parameter, however
>>> session already has a cancellation callback specified in the
>>> svn_ra_callbacks2_t structure. What is the relationship between the two?
>>> Is one of these going away?
>>
>> I've not looked at the session struct, but can explain a bit about the
>> reason get_commit_ev2() takes a cancellation func/baton.
>> Historically, we've had a number of places where we'd wrap an editor
>> with a cancellation editor, which was just a pain. Ev2 folds the
>> (optional) cancellation editor into the editor itself.
> Understood
>>
>> My guess is that in most places, the session cancellation callback and
>> the one provided to get_commit_ev2() will be the same, though they
>> will be invoked in different places.
>
> But how come other ra functions grab the cancellation callback from the ra
> session, but ev2 editor wants to get one passed directly to it rather
> than taking
> one from the ra session?
Ev2 is a generic API interface used across an large number of layers
in Subversion. (There is an editor interface for committing changes
to the FS layer, for example.) In many cases, these layers don't have
the concept of an ra session, so it would be a mistake for the Ev2
interface to use the ra session directly.
However, I think I see your point: svn_ra__get_commit_ev2() takes both
an ra_session_t *and* a cancellation func/baton. Since that API is
specific to the ra layer, I think we can drop the cancellation
func/baton from that interface, and just use those in the session
object when we create the Ev2 object. But looking at the definition
for svn_ra_session_t, it doesn't look like there is a cancellation
func/baton in there. Am I missing something?
>>
>>> * svn_editor_add_directory() function requires that
>>> "const apr_array_header_t *children" and "apr_hash_t *props" parameters
>>> cannot be NULL, instead an empty structure should be passed. However,
>>> svn_editor_alter_directory() permits the same parameters to be NULL.
>>> What is the reason for this difference?
>>
>> In the case of add_directory(), callers MUST provide the list of
>> children and properties, since they are not known a priori. However,
>> in the case of alter_directory(), if there are no changes, a NULL
>> parameter may be used to indicate that. (It would be rather pointless
>> to require clients to fetch the list of children and then replay them
>> back to the server if there are no changes.)
>>
> I think I was not very clear in asking the question. Lets take
> following use cases.
>
> 1) Add new directory without any children, with 1 property
> 2) Alter a directory, by adding 1 property
>
> In both cases caller needs to indicate that there are 0 children at
> play. In call to
> add_directory() 0 size array means no affected children. In call to
> alter_directory()
> NULL means no affected children.
In case (1), the caller needs to affirm that there are zero children
forthcoming, by providing a zero-length array. In case (2), since no
children are added or deleted, no array needs to be provided. The
difference is that in case (1), there isn't any existing list of
children, so one is required.
> Or another way, what is the behavior of alter_directory() if passed a
> 0 size children
> array rather than NULL?
If alter_directory() gets an array of size 0, it means "this directory
now has zero children; you should expect to see a delete() for each of
those children." If alter_directory() gets a NULL array it means
"none of the children are added or deleted." Big difference.
> Thank you for your time, as I might just being dense here.
No worries; I am often quite dense myself.
-Hyrum
Received on 2012-06-27 04:22:33 CEST