On Dec 17, 2007 7:20 PM, Jack Repenning <jrepenning@collab.net> wrote:
> On Dec 17, 2007, at 8:36 AM, David Glasser wrote:
>
> > This means that authors of a program
> > like svnmerge.py which invoke "svn" with many different subcommands
> > need to carefully figure out which subcommands take --non-interactive
> > and which do not;
>
> As a writer of scripts that invoke svn myself, I'm baffled here. Does
> not svnmerge.py also have to "carefully figure out which subcommands"
> take two arguments (as diff), or which can only use an URL, or which
> need a "--force", or myriad other matters not so susceptible to this
> blanket-acceptance approach?
Right, but don't 2-argument functions usually remain 2-argument? Or,
at least, a 2-argument version will still be supported, even if we
relax requirements to a 1-argument version where the second argument
is assumed, or a 3-argument version is also introduced.
> > and worse still, if in a future version we suddenly
> > come up with a new interactive mode in a subcommand that didn't take
> > --non-interactive before, the script will suddenly stop working.
>
> That sounds like an API change to me, and "presumptively a bug," as
> someone or other opined in IRC just Friday.
So, how do we react to that, then, if a command would suddenly become
interactive? You propose to keep 'svn merge' non-interactive and
implement a (now interactive) 'svn merge2'? That - in my eyes - is
even a bigger UI wart (although a consistent API).
bye,
Erik.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Mon Dec 17 21:11:14 2007