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

Re: CVS update: MODIFIED: libsvn_wc ...

From: <cmpilato_at_collab.net>
Date: 2001-06-09 15:15:13 CEST

Greg Stein <gstein@lyra.org> writes:

> Woah, woah, woah...
> "send bytes" ... this design is predicated on sending an arbitrary set of
> human-readable bytes, and expecting the stream to get them to the
> person.

Perhaps you missed that next paragraph that translates to: "I know
this method ain't the greatest. There's a better one to be found in
v-tables." ??

Regardless, that's not to say there's no value in having a library
feedback stream. Consider CVS in "trace mode" (or whatever that
ultra-verbose mode is). Sure, we could get the same effect by using
printf's *on a command-line client*, but that type of high-noise
feedback a) should be easily separable from the "important stuff"
(like what the trace editors are printing to stdout), and b) should be
easily consumed and displayed by a GUI client (I'm picturing the
"Output" window of MSVC, the bottom-most status window in WS_FTP, and
a host of other programs that want to tell the user things so rapidly
that simply replacing the status-bar text doesn't give anyone a chance
to read what the hell is going on. And I simply can't see the
advantage in having a callback *function* for each and every type of
thing such a trace mode would like to tell someone. So you end up
settling on a single call-back function that just provides
human-readable text meant to be dumped to someplace useful. And
that's what this is -- that single callback function is called

Whatever. The part of that commit related to a feedback stream is
easily revertable. The breakout of pool stuff into their own header
file is something that should have been done a long time ago anyway.

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:31 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.