Mark Phippard wrote:
>> If the API changes as I showed before as an example, then you could
>> simply ignore the additional params.
>
> I don't want to ignore them. I want to be able to add a check box to
> the blame UI that says "Merge sensitive" and if the user checks that
> box the blame output will just contain the merge sensitive info
> instead of what you currently get. If the API changes then I also
> have to change the UI to look at the new fields.
I certainly wouldn't mind if the API had a boolean param to enable the
'extended information'.
But for a GUI, I would prefer as less checkboxes as possible. Especially
for the blame command. Think about a user who wants to blame a file. He
first doesn't get the extended blame. But then, when he looks at the
blame, he finds that he would need the extended info too. Now he has to
blame the file again. That's not good. IMHO an UI should always provide
all the information that's available. Because the user doesn't know
beforehand if he will need the extended information or not.
>> You're forgetting that especially the svn_client_status() API isn't just
>> used (at least in TSVN) to show the user some nice dialog with all the
>> information - most of the information we get from there is used
>> internally. For example, the svn_client_ls() (or svn_client_list())
>> API's are used in TSVN for the repository browser. We don't have to show
>> that information directly in the repository browser. We can use any
>> additional information for e.g. determining whether to show a certain
>> command menu, or later to have information on how to call/execute a
>> certain command, depending on that additional information.
>>
>> I usually don't care at all how an UI would look like at this early
>> stage. I simply know that one day I will need that information for
>> something. I don't know yet for what exactly, but I'm sure I will have a
>> good use for it. I always do :)
>> And any information I get 'for free' from an API call is good: if I had
>> to call another API which might even need to contact the repository,
>> then that means the UI has to wait for that information first.
>>
>> For example, the log info doesn't indicate whether a changed path refers
>> to a file or a folder. But that information is necessary for many
>> commands we execute on those paths. TSVN now has to call
>> svn_client_info() every time for those commands to first find out
>> whether we're dealing with a file or a folder (e.g. diffing a file is
>> done by using svn_client_cat() twice, for folders we have to use
>> svn_client_diff_summarize()).
>
> I understand what you are saying but I do not think there will be
> anything "free" about this information (in terms of performance) and
> development resources certainly are not free. I do not care if
> someone wants to eventually rev the API to add something like this but
> I would rather see it happen due to a concrete use case where it has
> been thought through and the value of the extra information can be
> agreed upon. I'd hate to see a release delayed while these things are
> worked on, or for someone to implement info and status before they did
> blame and log.
I know that nothing is really 'free'. But we're in a very early stage
here. That means I like to request as much information as possible from
the APIs. If those who implement the feature then discover that it will
be a big performance hit or way too much work, that's ok. I just don't
want the API to get finished, and when I later request an API change to
hear 'if you've said that earlier, we could have done that without
problems. Now it's not possible anymore without a complete rewrite'.
Stefan
--
___
oo // \\ "De Chelonian Mobile"
(_,\/ \_/ \ TortoiseSVN
\ \_/_\_/> The coolest Interface to (Sub)Version Control
/_/ \_\ http://tortoisesvn.net
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Sat Apr 28 21:36:50 2007