Paul Burba wrote:
> On Thu, Apr 9, 2009 at 11:52 AM, C. Michael Pilato <cmpilato_at_collab.net> wrote:
>> I'm strongly considering reverting the behavioral change made in r31101, by
>> making the --depth option as applied to 'svn add' cover the depth of the
>> crawl (an operational depth) but still always set the recorded depth of the
>> newly added items to "infinity".
>>
>> The change in r31101 was discussed here:
>>
>> http://svn.haxx.se/dev/archive-2008-04/0444.shtml
>>
>> I contributed to the thread, but wish to recant the poor advice I gave there.
>>
>> Here's the problem: GUI clients often perform their operations using
>> shallow operational depths (because individual targets can be selected from
>> lists thereof). This means that any new directories added by such a client
>> essentially remain "unsubscribed" from changes which happen under them
>> later. That's inconsistent with Subversion's mission of promoting
>> collaboration and avoiding unexpected behaviors. I submit that just because
>> I was the guy that added an empty "trunk" to my repository doesn't mean I
>> don't want to see all the files and directories my colleagues add to in
>> future commits when I update.
>>
>> There are three approaches I could take here.
>>
>> The first is a slightly complex approach which allows a syntax like this:
>> 'svn add --depth OPERATION-DEPTH --set-depth RECORDED-DEPTH' (where both
>> depths default to "infinity"). As you can probably guess, this would
>> empower folks (including GUIs, though the APIs) to control both the
>> operational depth of the crawl for newly added items, as well as the
>> recorded depth of the newly added items. But I'm not sure there's much
>> value for the complexity here in terms of real-world use-cases, though, and
>> frankly I tied my brain in knot just considering the various interpretations
>> of that syntax.
>
> Our definitions of "slightly complex" clearly differ :-P I am under
> the impression that some of our depth behavior is fairly
> non-intuitive, e.g.
> http://subversion.tigris.org/ds/viewMessage.do?dsMessageId=1614711&dsForumId=462.
> I think a change like this goes too far to the right along the
> "easily does what I need" --> "does *something* through an absurd
> number of confusing options that may or may not be what I want"
> continuum.
>
>> The second is the simple approach and that I one I lean towards: always add
>> new items with a recorded depth of "infinity". This is just a partial
>> reversion of r31101 back to Subversion 1.5.x functionality. (I've attached
>> a patch for this.)
>>
>> The third approach is the simplest (for us): do nothing, and tell GUI
>> clients that after committing adds of new items of non-infinite depth
>> (resulting in revision X), they should then 'svn update --set-depth infinity
>> --revision X' each of those items behind the scenes so the user is
>> "subscribed" to future changes in those directories.
>
> I lean slightly to the do nothing approach, but since I can count on
> one hand the number of times I've used a GUI client to add a subtree
> my opinion probably isn't worth much. I certainly have no objections
> to making the default depth infinity.
I'm for the second approach here. Not just for UI clients but all
clients. I can't see a reason why someone would add a folder but then
not want to get the contents of that folder later. After all, that
folder is new - deciding that the contents are not needed in a users wc
can't be done in that stage. Only later when that new folder gets other
files added to it, a user can decide whether he needs those contents or not.
Consider for example this:
newfolder
newfolder\tempfile1
newfolder\tempfile2
newfolder\tempfile3
newfolder\importantfile
user want's to add that folder, but of course without the temp files.
The only way to do this is:
$ svn add newfolder --depth=empty
$ svn add newfolder\importantfile
because a simple
$ svn add newfolder
would also add the temp files. Sure, a user could first add the whole
folder and then revert the temp files, but that's much more work.
>> Index: subversion/libsvn_client/add.c
>> ===================================================================
>> --- subversion/libsvn_client/add.c (revision 37119)
>> +++ subversion/libsvn_client/add.c (working copy)
>> @@ -349,8 +349,8 @@
>> SVN_ERR(ctx->cancel_func(ctx->cancel_baton));
>>
>> /* Add this directory to revision control. */
>> - err = svn_wc_add3(dirname, adm_access, depth, NULL, SVN_INVALID_REVNUM,
>> - ctx->cancel_func, ctx->cancel_baton,
>> + err = svn_wc_add3(dirname, adm_access, svn_depth_infinity, NULL,
>> + SVN_INVALID_REVNUM, ctx->cancel_func, ctx->cancel_baton,
>> ctx->notify_func2, ctx->notify_baton2, pool);
>> if (err && err->apr_err == SVN_ERR_ENTRY_EXISTS && force)
>> svn_error_clear(err);
>>
Patch looks good to me.
+1 for committing this (and request for backporting to 1.6.x)
Stefan
--
___
oo // \\ "De Chelonian Mobile"
(_,\/ \_/ \ TortoiseSVN
\ \_/_\_/> The coolest Interface to (Sub)Version Control
/_/ \_\ http://tortoisesvn.net
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=462&dsMessageId=1906254
Received on 2009-04-25 09:27:25 CEST