On 27. 5. 25 18:06, Timofei Zhakov wrote:
On Tue, May 27, 2025 at 5:32 PM Timofei Zhakov <t...@chemodax.net> wrote:
Hi,
I noticed that there are two different functions in different
libraries (libsvn_subr and libsvn_client) which are doing almost
the same thing. But, one in subr is permanently deprecated.
Fine, it was moved to the client. But the thing is the old one
(which has been deprecated) is still used in svnadmin and svnsync
programs since they can't link with libsvn_client. And not only
that, but for some reason they rely on a private util
svn_opt__args_to_target_array.
It reveals two problems at the same time. First is deprecated api
usage in our cmdline which is bad. The hack with
svn_opt__args_to_target_array seems to hide this even more.
Also I don't see any reason to implement this function in
svnclient. It doesn't make sense to me.
Should we move the common one to the subr and use it then?
Please note that those functions are a little bit different in
behavior. The svn_opt's one doesn't implement some functionality
that svn_client's does.
--
Timofei Zhakov
Mmm, it seems like opt's one doesn't perform the checks that the
client's one does. Meaning that svnsync and svnadmin are incorrectly
parsing arguments.
See? SEE!!?? I *told* you it was a mess. :D
This stuff should all be in libsvn_subr/cmdline.c. I don't even remember
any more how this happened. I think that at one point I was even
considering creating a new library that would contain only the features
that command-line programs need; basically, command line conversion to
UTF-8 and the argument parser. But it's tied in with libsvn_subr anyway,
and that's already linked everywhere.
I suggest the goal should be to move this out of libsvn_cmdline and get
rid of the duplicates. Before that, some judicious use of svn blame and
svn log might give you an idea why it's currently done that way. I
really don't know, but we should, before we change anything.
-- Brane
