no patch for issue #1648

[kf...@collab.net]

I had planned to produce a patch for issue #1648 (real depth indicator
in APIs), just so we could have something concrete to vote on.

In case you don't recall, the idea of this change is to pave the way
for a bright future where we'd have, in addition to the mandatory ten
hours of asteroid mining per week, a --depth={0,1,infinity} option in
place of our current --recursive/--non-recursive.  With this change,
we'd be able to add the user option without changing any public
function interfaces.  I.e., we get to add a feature later without
causing binary incompatibility.

I wasn't in favor of making this change now, personally, but also
thought the patch wouldn't be too hard to make.  However, it turns out
to be *quite* involved, and I'm not going to attempt it.

We have the 'recurse' (or 'descend') paradigm all over the code.  In
the public svn_*.h files there are about 30 occurrences, spread across

   svn_client.h
   svn_repos.h
   svn_wc.h
   svn_ra.h

I don't see any point fixing just one of the public headers.  We'd
need to reflect the new interface in all of them, if the goal is to
avoid a future API change.  But IMHO that's way, way too big a change
for 1.0.  (And certainly too big to warrant my writing a patch just
for formality's sake :-). )

This isn't even counting internal function signatures, by the way,
which we'd ideally change along with the public interfaces, in order
to propagate a depth parameter as far possible before returing a
not-yet-implemented error on certain values.  We could skimp on the
propagation, I suppose, but one hates to add ugliness to the code
right before shipping...

Greg Hudson, who originally suggested this in

   http://subversion.tigris.org/servlets/ReadMsg?list=dev&msgNo=52297

...may have had something much simpler in mind than what I'm recoiling
from above.  Greg, if so, please describe.

Side note: there's an svn_recurse_kind enum in svn_types.h, which is
hardly used in the code.  It's very old, from r430.  Looks like maybe
we started to go down this road, but never finished?

-Karl

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org

Re: no patch for issue #1648 (API change for --depth)

[kf...@collab.net]

Greg Hudson <gh...@MIT.EDU> writes:
> Well, I initially only noticed the issue in the svn_ra interface, but
> I'm not surprised that it's more widespread.  Had I thought about it, I
> suppose I wouldn't have claimed that it would be a trivial change to
> make now.

You originally described the difficulty as "medium" (though for
different reasons), which turns out not to be far off base.

>   * The harder it would be to make the change now, the more awful it
>     would be to make the change in an API-preserving matter later.
> 
> As I've said before, I'm okay with deciding to punt this change on the
> basis that we're likely to never implement --depth (gstein's
> rationale).  I'm not so okay with deciding to punt this change because
> we think we will implement --depth but that it would be better to work
> around the current API than it would be to fix it while we have the
> chance.

I can't really judge how likely we are to implement --depth.  Have
never been a huge fan, but maybe one day it will seem more attractive
than it does now.

In any case, silence now doesn't mean we can't change our minds later.
There will, eventually, be an API-breaking release, and if we've
settled the --depth question by then, we can do the feature.

> So far no one has stood up in strong defense of --depth.  Once again,
> this is your big chance.

<listening>

-Karl

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org

Re: no patch for issue #1648 (API change for --depth)

[Greg Hudson <gh...@MIT.EDU>]

On Thu, 2003-12-25 at 23:49, kfogel@collab.net wrote:
> Greg Hudson, who originally suggested this in
> 
>    http://subversion.tigris.org/servlets/ReadMsg?list=dev&msgNo=52297
> 
> ...may have had something much simpler in mind than what I'm recoiling
> from above.  Greg, if so, please describe.

Well, I initially only noticed the issue in the svn_ra interface, but
I'm not surprised that it's more widespread.  Had I thought about it, I
suppose I wouldn't have claimed that it would be a trivial change to
make now.

I agree that it would be a fair amount of work to change this for 1.0. 
But I observe that:

  * It would still be essentially a rename operation, with little
    potential for destabilization.  I don't think it's "too big" of a
    change for 1.0, any more than fixing a bunch of error message is too
    big of a change.

    (The one wart with that claim is that right now, as I understand
    things, non-recursive commit is depth 0, while non-recursive
    everything else is depth 1.  So we would either have to change
    non-recursive commit to be depth 1, or we have to make the recursion
    parameter a three-element enum instead of a two-element enum, which
    means we have to add assertions or exceptions for the case where we
    get the unsupported value.)

  * The harder it would be to make the change now, the more awful it
    would be to make the change in an API-preserving matter later.

As I've said before, I'm okay with deciding to punt this change on the
basis that we're likely to never implement --depth (gstein's
rationale).  I'm not so okay with deciding to punt this change because
we think we will implement --depth but that it would be better to work
around the current API than it would be to fix it while we have the
chance.

So far no one has stood up in strong defense of --depth.  Once again,
this is your big chance.


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org