On 3/7/06, Peter N. Lundblad <peter@famlundblad.se> wrote:
> For notifications, yes, since the whole point of notification is to
> give the user instant feedback. For status, also yes, because it will
> often wait for the network (status -u) and there is no point in having
> the next process in the pipe wait when there is more data it could
> process.
*sigh*
The problem is that forcing a flush is a hack and doesn't solve
anyone's actual problems. It solves a completely contrived problem
that simply does not matter - and to which there are several
alternatives that don't impact everyone else.
That said, everyone else seems to disagree - fine.
> I never understood Justin's argument about cruft. It is a few
> one-liner changes to add fflush calls. That can't be a maintenance
> burden worth worryihg about.
But, that patch doesn't even begin to add it to half of the places
that we need it!
Where do we stop? In short, we are not going to be able to guarantee
line-buffering to a *file* across the entire client without a much
larger and substantial patch. We now have to audit every place we
produce any output and add flushing.
For example, one of the claims was that he really wants to support
diff. The change submitted was to the new summarize function - it
wouldn't touch diff at all. The diff printing code is deep down
inside our core libraries - libsvn_diff assumes that it has a stream
(svn_diff_file_output_unified2). At the minimum, we *must* add fflush
after every header write in diff. But, is that a valid assumption?
For the command-line - yes. But, for ViewVC? I'm not so sure. This
doesn't even mention that we'll have to setup a pty ourselves for
external diff to ensure we maintain the line-buffering semantics
regardless of usage.
A custom client can and should use these same code paths through our
bindings - but when we add fflush's, we've now gone and made all of
our bindings and other programs line-buffered too. Is that really
what we intend? Are we making the right call for all clients?
I will veto any patches that attempt to add a guarantee of
line-buffering but do not so consistently across the board. I refuse
to see us take half-hearted approaches - we're not CVS.
Enough people have said that flushing is a good idea that I'm sure
lots of people are willing to write the patch. I'd be willing to
review them. I do caution that a complete solution is going to be
larger than three one-liners. -- justin
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Tue Mar 7 18:13:01 2006