Joseph Galbraith wrote:
> Stefan Küng wrote:
>> Molle Bestefich wrote:
>>> Stefan Küng wrote:
>>>> In that case, you should file a bug with Araxis: a program should ignore
>>>> switches it doesn't know, or at least have a switch to do so.
>>>> I'm not talking about command line params but switches.
>>> Erh... what?
>>> If you shove random garbage at some program, it should err out.
>>> It should definitely NOT pretend all is well.
>> Not really. If you pass invalid params to it, then it should error out.
>> But ignore everything it doesn't know.
>> You know, the "garbage in -> garbage out" design is bad.
>>> (Point being that the user will not know whether they're doing it
>>> right or wrong if the options they type wrong are just ignored.)
>>> And how is a "switch" not a command line parameter?
>> A switch is something like "/switch" or "-switch"
>> a param is without the '/' or '-'.
>> For example:
>> svn checkout url path --ignore-externals
>> params: checkout, url, path
>> switch: --ignore-externals
>> As you can see, a param can't be ignored because it can only be valid or
>> invalid. A switch however is clearly distinct from a param and can be
>> valid (known), invalid (known but illegal, for example a --recursive
>> switch for operations which can't be done recursively) and unknown.
>> In case of an unknown switch, a program should simply ignore it.
>> It's different for command line tools like svn or e.g. 'copy', because
>> those really are used directly by the user. But GUI programs aren't used
>> that way but only called with command line params by other applications.
>> So they should not error out but ignore switches they don't know.
>>> I think this is a bug in TSVN :-).
>> Of course! It's always a bug in TSVN.
>> What do you suggest in this case? Provide yet another option to ommit
>> the param? But then some diff tools will know a 'readonly' param but
>> have it named differently, so what about those? A text box to enter the
>> param the external diff tool uses for 'readonly'? I'm starting to feel
>> sick just thinking of the bloating settings dialog...
> I personally suggest that we only pass the /readonly
> parameter if it is TortoiseMerge.
+1. IIUC the original bug report was a result of clicking the 'Resolved'
button in TMerge. That just doesn't exist in other apps, so there is no
pressing need for the /readonly switch.
> I've mentioned before that I don't have a problem if
> TortoiseMerge integrates better with TSVN than external tools
> (and therefore offers a richer feature set and fewer
> Maybe, if you are feeling generous, provide
> a check-box, "External tool compatible with TortoiseMerge
> command switches" which overrides this behavior.
I think there are just too many variations to make this worthwhile.
Maybe another tool uses /readonly, but it could be -r --readonly
--read-only or (for Micro$oft apps) -zRv. I don't think any app will set
out to be compatible with TMerge, and I don't think TMerge sets out to
be compatible with any other app.
> If you are feeling __extremely__ generous, provide
> registry settings for the value of each command switch
> we pass. I would not, however, expose these in the UI;
> let the users that want that level of customization
> us regedit.
How many different switches would we want to pass? Another approach
would be to add another substitution mechanism to the command line
parameters eg. %readonly=-r% (if read only switch is required, use
'/r'), which would avoid making the UI any more complicated for 'normal'
users. But again, is it really needed?
oo // \\ "De Chelonian Mobile"
(_,\/ \_/ \ TortoiseSVN
\ \_/_\_/> The coolest Interface to (Sub)Version Control
/_/ \_\ http://tortoisesvn.tigris.org
To unsubscribe, e-mail: firstname.lastname@example.org
For additional commands, e-mail: email@example.com
Received on Sat Apr 1 00:54:07 2006