On Wed, Feb 29, 2012 at 03:03, Daniel Shahaf <danielsh_at_elego.de> wrote:
> danielsh_at_tigris.org wrote on Tue, Feb 28, 2012 at 23:59:51 -0800:
>> Issue #|4131
>> Summary|svnmucc uses Subversion-private APIs
>> Status whiteboard|
>> Issue type|TASK
> Can someone create a 'svnmucc' component please?
>> ------- Additional comments from danielsh_at_tigris.org Tue Feb 28 23:59:50 -0800 2012 -------
>> svnmucc uses the Subversion-private API's, svn_cmdline__apply_config_options()
>> and svn_cmdline__parse_config_option(). However, as a tools/ project it should
>> use only public API's where possible:
>> % cd tools
>> % grep \#include **/*.c | grep private
>> client-side/svnmucc/svnmucc.c:#include "private/svn_cmdline_private.h"
>> dev/svnraisetreeconflict/main.c:#include "private/svn_wc_private.h"
>> dev/svnraisetreeconflict/main.c:#include "svn_private_config.h"
>> server-side/svn-rep-sharing-stats.c:#include "svn_private_config.h"
>> This could be fixed either by making svnmucc a core binary
> Honestly, shall we move it to subversion/svnmucc/ already?
I've never liked the cmdline parameters for this thing. Seems rather "magic".
> The test suite relies on it,
Hmm? When did that happen? I can just as readily claim that reliance
as a bug, than to say we should make it a standard tool.
> ASF infra now relies on it,
Not our problem :-)
> it's about to
> have its own issue tracker component...
You don't get to claim this one. I made a component, but that has no
bearing on whether it is a first-class tool or not. svnmerge.py has
had a component for ages.
> I'll get it done.
Please wait for some consensus before changing the product like that.
Received on 2012-02-29 09:50:52 CET