In this thread I'll just follow up on the API and support function issues, with
which I don't think there is any big difficulty.
In the nearby thread "[PATCH] Relative url support for all svn subcommand (that
make sense)" we can consider the command-line semantics - "repository of
current working directory" versus "repository of another argument".
Troy Curtis Jr wrote:
> On Nov 15, 2007 5:38 PM, Julian Foad <julianfoad@btopenworld.com> wrote:
>>Then you can add your array versions of the functions too, if you wish, for
>>convenience of the existing callers. When they were proposed as public APIs, I
>>would have objected to the addition of "array" versions on the grounds of too
>>much code and tests and overlap of functionality, and too specific to what the
>>existing callers want, but it's OK if they're private.
>
> I thought these functions would be valid as there are many other functions
> that operate on arrays and you will find in the more complete patch I am about
> to submit that those are the functions that get used in all but a couple of
> cases. If anything the array functions should be THE functions...except for
> those few cases. And even then they could be re-written to use the array
> functions.
A public API should have one version or the other (otherwise extending the API
in future tends to compound the variants and lead to an explosion of
functions). Given that these functions are going to be at a high level
(command-line support) where it's common to operate on arrays, I'd be happy
with the array version as THE (public) version. You can happily have both
versions in private if that's useful.
It was when looking at a low-level API that I was concerned about having array
operations at all.
>>It looks to me like all of this functionality belongs inside
>>svn_opt_args_to_target_array2(). Any reason why not? Does anything outside that
>>need to know? That's the appropriate level, where raw user input is converted
>>to standard forms.
>
> Ah, that would be nice wouldn't it? This is exactly where I wanted to stick
> it, everything calls this function. Problem solved. However, like David said
> I can't put svn_wc_* functions in there because of circular library
> dependencies. And I can't impose requiring a repository root url from the
> client for *possibly* relative urls.
That dependency problem is easy to solve. Instead of the command-line client
directly calling that low-level "svn_opt" function from all of those places, it
should call a function at or near its own level instead.
(I think it's a historical mistake that libraries like svn_wc use types
provided by svn_opt, thus putting svn_opt low down in the dependency graph, but
we don't need to fix that right now.)
Regards,
- Julian
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Fri Nov 16 21:55:57 2007