On 3/7/06, Stefan Haller <haller@ableton.com> wrote:
> Others have pointed out that the patch is not only useful to my
> particular problem, but also when you redirect output to a file and look
> at it with tail -f, or pipe it through tee, things like that. You
> assert that nobody cares about that, which I don't believe. Why should
> this be less important for svn than it is for make or other tools that
> produce line-based output?
Because to me no one has yet made a convincing argument that the lack
of flushing is a demonstrable and damaging problem that requires us to
fix our core code.
> As for my specific problem: to me, using a pty feels like much more the
> wrong solution than having svn flush more often.
Well, it'd work with all prior and future releases.
> And a custom notification callback: maybe I don't understand well enough
> what you are suggesting, so could you please briefly outline what you
> think I should do in order to post-process the output of, say,
> "svn merge". I want it to behave exactly like svn merge, with the same
> option handling (including future enhancements); I don't see how I can
> do that without completely reimplementing merge-cmd.c and notify.c in
> python.
The only thing you'd need to implement is the print logic that you
want. You'd implement svn_wc_notify_func2_t and set that in your
svn_client_ctx. You can call the diff/merge/whatever functions from
your application directly rather than invoking a binary application
and your notifier will get invoked. You'll also get all of the
information you want directly from the bindings without having to
parse anything thing from stdout. You can display it however you like
with as much or as little buffering as you'd like.
The bindings are the way every front-end to Subversion should be written.
> > > Does it help if I collect some timing data of some sort? If
> > > so, what exactly would be useful?
> >
> > Any timing data that you could produce would not address my
> > fundamental concerns that the core is the wrong place to address this.
>
> I don't get it. You have heard several different reasons why the change
> can be useful to some people; and you have heard that the change does no
> harm (actually, makes no difference at all) for everybody else. Still
> you object to it, "just because"?
Uh, no. You haven't been paying attention to my concerns then.
Our command-line client is not supposed to serve everyone's
customization needs. To continually add bloat to support one minor
case when there are far better alternative avenues to support the case
should be against our philosophy. It's why we have the bindings - if
the command-line client doesn't fit what you personally need, you
should use the bindings and write your own notifier rather than expect
the command-line client to gain a feature that only your app would
ever truly care about. -- 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 11:14:51 2006