Mark Phippard wrote:
>> I don't understand. Do you call the svn client from Subclipse and parse
>> its output? I don't think you do it that way, so why bother with how the
>> svn client will show the additional information? It shouldn't bother you
>> how many columns there are since you would be using the blame callback
>> which I think will simply have some more callback params to use.
>>
>> Or am I completely wrong here?
>
> We use the blame callback API, but if this approach is taken then
> presumably the API has to change too which means our implementation
> does need to account for this. I would rather let the process that
> runs blame API set the boolean correctly and let the output remain the
> same.
If the API changes as I showed before as an example, then you could
simply ignore the additional params.
>> "svn info, svn ls --verbose and svn status --show-updates are purposely
>> not included in this list, on the grounds that one would typically need
>> more information than they can reasonably provide. Adding more output to
>> these commands would clutter their interface, further reducing their
>> utility."
>>
>> I think here I disagree. I'm ok with this if you're only referring to
>> the command line client. But the API should still provide that
>> information if it's available. You don't know how other (UI) clients
>> could make good use of such information. Always remember, an UI client
>> isn't limited to 80 chars screen width.
>>
>> Especially the svn_client_status() function should return that
>> information if it is available.
>
> The issue is that these API's are setup to show single values. When
> you are dealing with an entire file a commit from a merge could have
> changes to the file from many revisions and authors. How are commands
> like status, info and ls (even in a GUI) possibly going to deal with
> that?
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()).
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 20:22:09 2007