Re: deliberate user unfriendlyness vs training users brains/fingers

[kf...@collab.net]

solo turn <so...@yahoo.com> writes:
> svn seems to get an improving track record in introducing
> "user-unfriendlyness". there are things which introduced a less
> usable style, and there are things where users are forgotten right
> from the beginning. examples:
>
> * "svn revert -R" in contrary to "svn blabla -N" in other cases
>   svn operates recursively, but not always.
>   thanks to svn developers dumb users brains are now trained
>   by learning different svn command semantics
>   (instead of issueing a warning "really recursive y/n").

I almost didn't respond to this, but then thought maybe it's worth it
for other people to understand why/how these decisions were made.

The revert -R decision was deliberate.  Because revert is so serious
(it can lose your uncommitted changes), we decided that command should
not default to recursive.  Since users won't be habituated to -R
normally, the failure mode here would be that *less* gets reverted
than you wanted, rather than more.  That's a good thing.

What you describe as a "warning" is in fact a prompt, and prompting
make SVN less scriptable and predictable.  That's why we avoid it when
we can.

> * issueing help text has to be done explicitely
>    $ svnadmin
>    Type 'svnadmin help' for usage.
> 
>    $ svn ls file:///rep -m ""
>    subcommand 'list' doesn't accept option '-m [--message] arg'
>    Type 'svn help list' for usage.
> 
>   instead of giving the help text directly (case 1), or doing the command
>   and issue a warning (case 2), users are trained to retype that command,
>   to finally get the help text.

Another deliberate decision.

Experienced users prefer this behavior, rather than getting a faceful
of help text each time and having to wade through it to figure out a
mistake which might be clear on a moment's thought.  The philosophy
is: describe what went wrong in brief, and provide an "escape hatch"
via which to get more help.

I couldn't understand the last part of your sentence, by the way.

> * "svn import" trains users brains by learning that files and directories are
>   treated differently:
>   $ touch imptest/ts.txt
>   $ svn import imptest/ file:///rep -m ""
>   Adding         imptest/ts.txt
>   --> the specified "imptest" is not added, but the contents "ts.txt"
>   $ touch ts3.txt
>   $ svn import ts3.txt file:///`pwd`/rep/ts3.txt -m ""
>   Adding         ts3.txt
>   --> the specified thing is added.

I don't really understand what this means, but insofar as I can piece
together a meaning, it is an inaccurate description of how Subversion
behaves.

> * accept certificates permanently
>   svn developers think that certificates have to be valid,
>   and dumb users should annoy dumb server operators to make
>   their certificates valid. so there is no option any more
>   to store such a certificate.

You often have no idea (or a wrong idea) of what the "svn developers"
think, so please don't characterize things this way :-).

(Yes, I realize you're trying to be humorous, but it's also clear that
there's more than a grain of sincerity in the way you're phrasing all
this.)

I don't know the details of this particular behavior, so I can't
comment on whether your assertions are accurate or not.

> * paths given with "\" on windows to disallow command-line
>   url/path copy paste for svn commands
>   new way:
>   $ svn st
>   U   bla\bla\bla.txt
>   even in cygwin environment. ther is no copy-paste any more
>   to do:
>   $ svn somecommand http://server/bla/bla/bla.txt
>   
>   svn developers think that dumb users on windows anyway do not
>   use command line, and if they do, they should learn to type. 
>   output has to be "pure", maybe there is somebody writing a
>   script using this output, and win user does not know
>   how to use a "bla/bla/.." path.

I don't remember what the justification for this was, if any.  You
might try searching the archives, or (gasp!) *asking* why Subversion
behaves the way it does instead of stating that it's wrong.  Maybe
it's an oversight, or maybe there's a good reason.

> * first lock working copy (which can take long) and afterwards ask
>   questions if you switch to another window in the meantime you
>   risk a session timeout and restart from scratch.

This is a known bug, and filed.  What the "svn developers think" is
that prioritization is not a choice, the only choice is in how we
prioritize.

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org

Re: deliberate user unfriendlyness vs training users brains/fingers

[solo turn <so...@yahoo.com>]

--- Tobias Ringstrom <to...@ringstrom.mine.nu> wrote:
> >>* accept certificates permanently
> >>  svn developers think that certificates have to be valid,
> >>  and dumb users should annoy dumb server operators to make
> >>  their certificates valid. so there is no option any more
> >>  to store such a certificate.
> He has store-auth-creds = no in his config file.

yes, tobias. the problem is, that this option brings together private and public data. we do not
want to store passwords (private), and we do not care, if (anyway public) certificates are stored.


__________________________________
Do you Yahoo!?
Yahoo! Hotjobs: Enter the "Signing Bonus" Sweepstakes
http://hotjobs.sweepstakes.yahoo.com/signingbonus

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org

Re: deliberate user unfriendlyness vs training users brains/fingers

[Tobias Ringstrom <to...@ringstrom.mine.nu>]

kfogel@collab.net wrote:
>>* accept certificates permanently
>>  svn developers think that certificates have to be valid,
>>  and dumb users should annoy dumb server operators to make
>>  their certificates valid. so there is no option any more
>>  to store such a certificate.
> 
> You often have no idea (or a wrong idea) of what the "svn developers"
> think, so please don't characterize things this way :-).
> 
> (Yes, I realize you're trying to be humorous, but it's also clear that
> there's more than a grain of sincerity in the way you're phrasing all
> this.)
> 
> I don't know the details of this particular behavior, so I can't
> comment on whether your assertions are accurate or not.

He has store-auth-creds = no in his config file.

/Tobias


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org

Re: deliberate user unfriendlyness vs training users brains/fingers

[solo turn <so...@yahoo.com>]

--- kfogel@collab.net wrote:
> solo turn <so...@yahoo.com> writes:
> > * "svn revert -R" in contrary to "svn blabla -N" in other cases
> >   svn operates recursively, but not always.
> >   thanks to svn developers dumb users brains are now trained
> >   by learning different svn command semantics
> >   (instead of issueing a warning "really recursive y/n").
> 
> The revert -R decision was deliberate.  Because revert is so serious
> (it can lose your uncommitted changes), we decided that command should
> not default to recursive.
...
> What you describe as a "warning" is in fact a prompt, and prompting
> make SVN less scriptable and predictable.  That's why we avoid it when
> we can.

i can understand that, and you are perfectly right, but maybe it is just solved inconsistently:

$ svn up -N --non-interactive
has the same semantics than
$ svn revert

why not having:
$ svn revert --non-interactive
if you don't like warnings, and why not have a warning if you are afraid your data is gone
forever?

> > * issueing help text has to be done explicitely
> >    $ svnadmin
> >    Type 'svnadmin help' for usage.
> > 
> >    $ svn ls file:///rep -m ""
> >    subcommand 'list' doesn't accept option '-m [--message] arg'
> >    Type 'svn help list' for usage.
> > 
> >   instead of giving the help text directly (case 1), or doing the command
> >   and issue a warning (case 2), users are trained to retype that command,
> >   to finally get the help text.
> 
> Another deliberate decision.
> 
> Experienced users prefer this behavior, rather than getting a faceful
> of help text each time and having to wade through it to figure out a
> mistake which might be clear on a moment's thought.  The philosophy
> is: describe what went wrong in brief, and provide an "escape hatch"
> via which to get more help.
> 
> I couldn't understand the last part of your sentence, by the way.
i ment: if you do not know your error, you end up typing what the program suggests you should
type, instead of doing it for you. as svn developper, you are quite exceptional, you of course
know all this stuff by heart, and this is MUCH more than an experienced user.

> > * "svn import" trains users brains by learning that files and directories are
> >   treated differently:
> >   $ touch imptest/ts.txt
> >   $ svn import imptest/ file:///rep -m ""
> >   Adding         imptest/ts.txt
> >   --> the specified "imptest" is not added, but the contents "ts.txt"
> >   $ touch ts3.txt
> >   $ svn import ts3.txt file:///`pwd`/rep/ts3.txt -m ""
> >   Adding         ts3.txt
> >   --> the specified thing is added.
> 
> I don't really understand what this means, but insofar as I can piece
> together a meaning, it is an inaccurate description of how Subversion
> behaves.
imo to be consistent it should be:
svn import <directoryname> creates a directory <directoryname> in the repository, and below that,
create the contents. if i want just the contents i would write svn import <directory>/*.


> > * paths given with "\" on windows to disallow command-line
> >   url/path copy paste for svn commands
> >   new way:
> >   $ svn st
> >   U   bla\bla\bla.txt
> >   even in cygwin environment. ther is no copy-paste any more
> >   to do:
> >   $ svn somecommand http://server/bla/bla/bla.txt
> >   
> >   svn developers think that dumb users on windows anyway do not
> >   use command line, and if they do, they should learn to type. 
> >   output has to be "pure", maybe there is somebody writing a
> >   script using this output, and win user does not know
> >   how to use a "bla/bla/.." path.
> 
> I don't remember what the justification for this was, if any.  You
> might try searching the archives, or (gasp!) *asking* why Subversion
> behaves the way it does instead of stating that it's wrong.  Maybe
> it's an oversight, or maybe there's a good reason.

there was a reason: "windows path names contain \, not /". we ended up typing for this reason (or
"recompile your own svn" :)



__________________________________
Do you Yahoo!?
Yahoo! Hotjobs: Enter the "Signing Bonus" Sweepstakes
http://hotjobs.sweepstakes.yahoo.com/signingbonus

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org