On Dec 17, 2007 6:50 PM, Brian W. Fitzpatrick <fitz@red-bean.com> wrote:
> On Dec 17, 2007 11:10 AM, David Glasser <glasser@davidglasser.net> wrote:
> > On Dec 17, 2007 9:02 AM, Erik Huelsmann <ehuels@gmail.com> wrote:
> > > For now, I too fail to see why it's (in this case) a UI wart to have
> > > --username, --password and --non-interactive options to the svn
> > > client. Surely I do understand it's a UI wart to support other options
> > > (like --stop-on-copy), but I think the ones above are generic enough
> > > to have commands suddenly develop the need for them. (See our 'sudden'
> > > requirement for 'svn copy' to have them!)
> >
> > Additionally, unless I'm missing something the main point of having
> > these three options in the first place is to use them in scripts. So
> > making it easier for script writers to use them is a good thing.
>
> I totally disagree. I posit that people who write scripts to wrap the
> svn client are a subset of people who use svn. I further posit that
> these people are a tiny minority of people who use svn. Are you
> telling the that it's too hard for people to either keep track of what
> commands take these options or to do simple discovery? I refuse to
> believe that.
I - however - *do* believe that the people who then use those scripts
have no idea about the real interactions of the script with the svn
client. I also believe that these scripts - as svnmerge.py - are
widely used. This - to me - means that the --non-interactive and
possibly --username and --password options *should* be available on
all commands for scripts to be guaranteed to work in a forward
compatible way with our command line interface.
> Just because svn is a command line application doesn't mean that we
> can get away with gluing a bunch of crap on to our UI. Keeping our
> command line client usable and simple has always been a priority.
Right. But we also declared that our command line client should be an
'api' for script writers. It turns out that script writers (as the
authors of svnmerge.py) code to the current behaviours of the command
line client. That makes the current behaviour - including
non-interactivity - the API. Surely adding an 'svn copy2' command
would be a greater wart than adding --non-interactive and
--username/--password now? If we do that now, at least all svn copy
commands (and all other commands) are forward compatible and
predictable from a script-writer POV. Saying script-writers are a very
small minority disregards the fact that those scripts have users too.
> If a user runs 'svn help add' and sees that it takes --username and
> --password, they're going to wonder what it's used for.
So, if that's the problem, why not resolve *that* issue?
> > If the 'help' output implies too strongly that any command that takes
> > --non-interactive absolutely has a way to be interactive right now
> > (for example), then perhaps that needs to be changed.
>
> That would be a nasty hack on top of a nasty hack.
Why? Discarding unused arguments to provide a stable forward
compatible API isn't a hack, is it?
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 20:56:27 2007