[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

RE: Re: Trace and cancel update patches part 2

From: Bill Tutt <billtut_at_microsoft.com>
Date: 2002-01-10 12:47:59 CET

> From: Greg Stein [mailto:gstein@lyra.org]
>
> On Sun, Dec 23, 2001 at 10:56:21PM -0800, Bill Tutt wrote:
> > Here is the "move the trace commit, and trace update editors from
the
> > command line client and into libsvn_client" patch.
>
> This patch is dependent upon "part 3" because p3 is needed to remove
the
> printf() calls introduced into libsvn_client by this patch.
>

File movement patches are better off reviewed on their own, whether or
not they're committed in unison is another matter altogether. Didn't you
say that? :)

> However, p3 also issues formatted strings. Similar to Kevin, I have
> reservations about that. In fact, quite serious reservations. I don't
> think
> that libsvn_client should be in the business of formatting anything
for
> the
> user.
>
> IMO, the ui_funcs structure that you introduced should have a wide
variety
> of callbacks. You could have a function says thats file_op(op,
filename)
> where op is one of ADDED or DELETED or whatever. Or, have file_added()
etc.
> Essentially, pass the relevant data and let the callback do the
formatting.
>

I agree, this is just a small part of what will eventually be needed by
the trace editors, and this is a small start towards that goal. (small
patches remember? :) )

> I believe you responded to Kevin and said "but all clients shouldn't
have
> to
> duplicate the formatting". That's bogus. What'll eventually happen is
that
> some client will have to *parse* that string to figure out what is
> happening. Then we're doomed.
>

A common formatting function would still be useful, however they
(clients) can't parse the string to figure out what's happening. The
string doesn't have enough data to tell them all of the details they
need. They should update the trace editor as you suggested and add more
callbacks. When I get around to doing work on doing a commit from the
COM layer that's when I'll probably be updating the trace editors to be
more callback oriented. (Mostly because I need to hook property conflict
events in order to be semi-efficient. The COM layer already gets
efficient notifications when files in the current directory sub tree
changes.) I'd add the rest then as well to have the code from being to
terribly lame.

Besides, somebody might beat me to adding all of those fun callback
methods. :)

Thanks for getting to this stuff!
Bill

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Sat Oct 21 14:36:55 2006

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.