[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: svn commit: r32998 - trunk/subversion/libsvn_wc

From: Karl Fogel <kfogel_at_red-bean.com>
Date: Tue, 09 Sep 2008 12:26:02 -0400

"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

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.