--- kfogel@collab.net wrote:
> solo turn <soloturn99@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
Received on Mon Jan 19 19:59:51 2004