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

Re: Bug with SVN::Client::diff() and in-memory files

From: Malcolm Rowe <malcolm-svn-dev_at_farside.org.uk>
Date: 2006-11-09 18:51:31 CET

On Thu, Nov 09, 2006 at 02:12:10PM +0100, Peter Lundblad wrote:
> > Actually solving the problem would require us to be able to exec()
> > commands with stdin/out/err connected to non-file-handle-backed streams.
> > Of course, that's impossible.
> >
> No, we don't need that. We could use pipes and forward to our own stream
> objects if we want to.

I think I'm agreeing with you: I meant that we can't literally just
pass streams to be inherited by child processes. What you said above,
I think I said in more detail next:

> > Instead, we'd need to create a temporary file (pipe?) to store the
> > input or output and then connect filehandles to that, marshalling the
> > data to or from the svn_stream_t* to the filehandle as necessary.
> > (We'd also want the ability to detect and extract filehandles from
> > apr_file_t-wrapping-svn_stream_t's, because I suspect we'd want to
> > short-circuit all that nonsense in the usual case).
> >
> Why?

Why would we want to special-case the file-wrapping-stream case? Only
because it seems a little mad to use something that provides a pipe to
a pipe reader/stream writer that's wrapping a file handle when we could
instead just provide the file handle directly.

> I don't think it would be too hard, actually. It wouldn't be worth the
> complexity just for this Perl use case, but I think it would improve
> our APIs in general. In general, we should pass streams of data using
> svn_stream_t objects in our APIs rather than files.

I completely agree; I just meant that it sounded like a lot of work for
the one specific case.


  • application/pgp-signature attachment: stored
Received on Thu Nov 9 18:53:45 2006

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