On 4/28/07, Stefan Küng <tortoisesvn@gmail.com> wrote:
> 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.
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.
> >> "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()).
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.
--
Thanks
Mark Phippard
http://markphip.blogspot.com/
---------------------------------------------------------------------
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:23:17 2007