Hi,
back to the pipe-topic.
On Wednesday 01 August 2012 12:42:48 Jonathan Nieder wrote:
Hi again,
Florian Achleitner wrote:
When the first line arrives at the remote-helper, it starts importing one
line at a time, leaving the remaining lines in the pipe.
For importing it requires the
Hi again,
Florian Achleitner wrote:
back to the pipe-topic.
Ok, thanks.
[...]
The way it's supposed to work is that in a bidi-import, the remote
helper reads in the entire list of refs to be imported and only once
the newline indicating that that list is over arrives starts writing
its
Hi again,
Florian Achleitner wrote:
Another alternative would be to use the existing --cat-pipe-fd argument. But
that requires to open the fifo before execing fast-import and makes us
dependent on the posix model of forking and inheriting file descriptors
Let me elaborate on this, which I
On Sunday 12 August 2012 09:12:58 Jonathan Nieder wrote:
Hi again,
Florian Achleitner wrote:
back to the pipe-topic.
Ok, thanks.
[...]
The way it's supposed to work is that in a bidi-import, the remote
helper reads in the entire list of refs to be imported and only once
the
Florian Achleitner wrote:
This is how I see it, probably it's all wrong:
I thought the main problem is, that we don't want processes to have *more than
three pipes attached*, i.e. stdout, stdin, stderr, because existing APIs don't
allow it.
Oh, that makes sense. Thanks for explaining, and
On Tuesday 31 July 2012 15:43:57 Jonathan Nieder wrote:
Florian Achleitner wrote:
I haven't tried that yet, nor do I remember anything where I've already
seen two processes writing to the same pipe.
It's a perfectly normal and well supported thing to do.
I played around with a little
Hi again,
Florian Achleitner wrote:
When the first line arrives at the remote-helper, it starts importing one
line
at a time, leaving the remaining lines in the pipe.
For importing it requires the data from fast-import, which would be mixed
with
import lines or queued at the end of
On Monday 30 July 2012 11:55:02 Jonathan Nieder wrote:
Florian Achleitner wrote:
Hm .. that would mean, that both fast-import and git (transport-helper)
would write to the remote-helper's stdin, right?
Yes, first git writes the list of refs to import, and then fast-import
writes feedback
Florian Achleitner wrote:
I haven't tried that yet, nor do I remember anything where I've already seen
two processes writing to the same pipe.
It's a perfectly normal and well supported thing to do.
[...]
Will try that in test-program..
Thanks.
Good luck,
Jonathan
--
To unsubscribe from
On Saturday 28 July 2012 02:00:31 Jonathan Nieder wrote:
Thanks for explaining. Now we've discussed a few different approproaches,
none of which is perfect.
a. use --cat-blob-fd, no FIFO
Doing this unconditionally would break platforms that don't support
--cat-blob-fd=(descriptor
On Thursday 26 July 2012 10:29:51 Junio C Hamano wrote:
Of course, if the dispatch loop has to be rewritten so that a
central dispatcher decides what to call, individual input handlers
do not need to say NOT_HANDLED nor TERMINATE, as the central
dispatcher should keep track of the overall
Florian Achleitner wrote:
On Saturday 28 July 2012 02:00:31 Jonathan Nieder wrote:
a. use --cat-blob-fd, no FIFO
[...]
* Make it conditional --- only do it (1) we are not on Windows and
(2) the remote helper requests backflow by advertising the
import-bidi capability.
* Let
On Monday 30 July 2012 03:29:52 Jonathan Nieder wrote:
Generally I like your prefered solution.
I think there's one problem:
The pipe needs to be created before the fork, so that the fd can be
inherited.
The relevant pipe already exists at that point: the remote helper's
stdin.
In
Florian Achleitner wrote:
Hm .. that would mean, that both fast-import and git (transport-helper) would
write to the remote-helper's stdin, right?
Yes, first git writes the list of refs to import, and then fast-import
writes feedback during the import. Is that a problem?
--
To unsubscribe
Hi,
Some quick details.
Florian Achleitner wrote:
Anyways, specifying cat-blob-fd is not
allowed via the 'option' command (see Documentation and 85c62395).
It wouldn't make too much sense, because the file descriptor must be set up
by
the parent.
Florian Achleitner wrote:
So I should kick printd out?
I think so, yes.
git log -SGIT_TRANSPORT_HELPER_DEBUG transport-helper.c tells me
that that option was added to make the transport-helper machinery make
noise to make it obvious at what stage a remote helper has deadlocked.
On Thursday 26 July 2012 09:54:26 Jonathan Nieder wrote:
Since the svn remote helper relies on this, it seems worth working on,
yeah. As for how to spend your time (and whether to beg someone else
to work on it instead :)): I'm not sure what's on your plate or where
you are with respect to
Hi!
Most of this review went into the new version..
For the remaining points, some comments follow.
On Monday 02 July 2012 06:07:41 Jonathan Nieder wrote:
Hi,
Florian Achleitner wrote:
--- /dev/null
+++ b/contrib/svn-fe/remote-svn.c
@@ -0,0 +1,207 @@
+
+#include stdlib.h
Florian Achleitner wrote:
Most of this review went into the new version..
For the remaining points, some comments follow.
Thanks for this.
On Monday 02 July 2012 06:07:41 Jonathan Nieder wrote:
[...]
+
+static inline void printd(const char* fmt, ...)
[...]
Why not use trace_printf and
On Jul 2, 2012, at 4:07 AM, Jonathan Nieder jrnie...@gmail.com wrote:
[...]
diff: Use fifo instead of pipe: Retrieve the name of the pipe from env and
open it
for svndump.
I'd prefer to avoid this if possible, since it means having to decide
where the pipe goes on the filesystem. Can
(cc-ing Ram since he's also knowledgeable about remote-helper protocol)
Florian Achleitner wrote:
On Thursday 26 July 2012 06:40:39 Jonathan Nieder wrote:
Though I still
think the way forward is to keep using plain pipes internally for now
On Thursday 26 July 2012 04:08:42 Jonathan Nieder wrote:
Florian Achleitner wrote:
On Monday 02 July 2012 06:07:41 Jonathan Nieder wrote:
[...]
+
+static inline void printd(const char* fmt, ...)
[...]
Why not use trace_printf and avoid the complication?
Hm.. I tried. It
Jonathan Nieder jrnie...@gmail.com writes:
[...]
+
+enum cmd_result { SUCCESS, NOT_HANDLED, ERROR };
[...]
Hm.. the enum now has SUCCESS, NOT_HANDLED, TERMINATE.
Much nicer.
I think this tristate return value could be avoided entirely because...
... it isn't needed at the moment.
I am
23 matches
Mail list logo
