Simon Large wrote:
> 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
>> problems.)
>>
>> 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?
>
> Simon
>
Maybe non TortoiseMerge compatible tools could be called from a batch
file which filters out the unwanted "guff" on the command line.
Peter
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tortoisesvn.tigris.org
For additional commands, e-mail: dev-help@tortoisesvn.tigris.org
Received on Sat Apr 1 02:37:31 2006