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

Re: svn commit: r1394332 - /subversion/trunk/subversion/include/svn_client.h

From: C. Michael Pilato <cmpilato_at_collab.net>
Date: Fri, 5 Oct 2012 08:49:26 -0400

On 10/04/2012 10:06 PM, Ben Reser wrote:
> On Thu, Oct 4, 2012 at 6:48 PM, C. Michael Pilato <cmpilato_at_collab.net> wrote:
>> On 10/04/2012 09:46 PM, C. Michael Pilato wrote:
>>> Perhaps you meant something like:
>>>
>>> "... it will enter versioned directories, scheduling any unversioned
>>> children thereof for addition."
>>
>> Sorry -- I just saw that you fixed the *unversioned* bit. My additional
>> questions remain:
>>
>>> But why only #svn_depth_infinity? Will it not do the same (to different
>>> depths, of course) for #svn_depth_files and #svn_depth_immediates?
>
> How about:
>
> [[[
> When used with @a depth it will enter versioned directories (per the
> rules of the argument), and schedule unversioned children.
> ]]]
>

Honestly, the original phrasing of the docstring remains a better starting
point, in my opinion. Your changes lose the context that all this
discussion about depth and unversioned items in a versioned tree are still
tried primarily to the use of the force flag. So if it were up to me, I
would restore that paragraph to the state it was in and make only minor changes:

  * If @a force is not set and @a path is already under version
  * control, return the error #SVN_ERR_ENTRY_EXISTS. If @a force is
  * set, do not error on already-versioned items. When used on a
  * directory in conjunction with a @a depth value greater than
  * #svn_depth_empty, this has the effect of scheduling for addition
  * any unversioned files and directories scattered within even a
  * versioned tree (up to @a depth).

-- 
C. Michael Pilato <cmpilato_at_collab.net>
CollabNet   <>   www.collab.net   <>   Enterprise Cloud Development

Received on 2012-10-05 14:50:06 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.