"Greg Stein" <gstein_at_gmail.com> writes:
> I was thinking that "replaced without history" is just an add. The
> fact that it "shadows" a previously-deleted item is a different
> question, and is answered by a new boolean named "base_shadowed" in
> the _read_info() API. This is similar to copying or moving a node over
> the top of another. We're talking about the status of what is there
> now. The fact that something *was* there is orthogonal.
Ah. So when the shadowed thing is also scheduled for deletion, then
that's a replacement. Okay.
>> Also, for the 'moved' and 'copied' enums, would they refer to the source
>> or dest of the operation?
>
> This is the status of the destination, just like our current interface.
>
> But your point is good: what about the source of a move. In order for
> this API to properly represent a move, the source is not "deleted",
> but "moved away". I'll update the enum to clarify that situation.
Sounds good.
> Note: I plan to have the WC *support* these moves. Whether the callers
> use it or not... we will need to ripple that out. For example, maybe
> the client library would start to record moves, but when we send them
> to the server, they just become add/delete pairs.
Yes... slowly, eventually, we will have real moves in Subversion :-).
>>> @@ -350,7 +364,7 @@ svn_wc__db_op_copy_url(svn_wc__db_t *db,
>>> apr_pool_t *scratch_pool);
>>>
>>>
>>> -/* ### props, children may be NULL
>>> +/* ### props may be NULL. children must be known before calling.
>>> *
>>> * ### KFF: Okay, if children can be NULL here, then it should be
>>> * ### able to be NULL up in svn_wc__db_base_add_directory().
>>
>> I didn't understand "children must be known before calling". Does it
>> mean that children cannot be changed after calling or something?
>
> The set cannot be changed as a whole [so specify the initial set up
> front], but you can add/remove children through the other APIs (e.g.
> op_add_file).
>
> Primarily, this was a note/anwer to myself that you must specify
> children rather than make it optional. NULL implies no children rather
> than "don't care to specify at this time".
Okay. It'll need to be expanded when intended for a wider audience :-).
>>> + ### original_url will be NULL if this node is not copied/moved
>>> + ### original_rev will be SVN_INVALID_REVNUM if this node is not copied/moved
>>
>> s/will/must/ ?
>
> Well, these are OUT params, and MUST implies a requirement-for-action.
> Doesn't fit very well here. I guess if you're talking about the
> implementation... :-P
My braino, please ignore.
> My intent is to allow NULL for any of the params indicating "I don't
> care about that", so the implementation can optimize its behavior in
> different ways if you are interested in just a subset.
Yeah. I wish we'd followed that principle consistently in all of
Subversion's out-param functions.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe_at_subversion.tigris.org
For additional commands, e-mail: dev-help_at_subversion.tigris.org
Received on 2008-09-09 18:26:16 CEST