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, an
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
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
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
>
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 requir
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 o
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 littl
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 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 fe
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 f
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.
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.
>>
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 s
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=(descri
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.
GIT_TRANSPOR
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 paren
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
Jonathan Nieder 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 no
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?
> >
> >
(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 no
On Thursday 26 July 2012 06:40:39 Jonathan Nieder wrote:
> Steven Michalske wrote:
> > On Jul 2, 2012, at 4:07 AM, Jonathan Nieder 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
Steven Michalske wrote:
> On Jul 2, 2012, at 4:07 AM, Jonathan Nieder 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
On Jul 2, 2012, at 4:07 AM, Jonathan Nieder 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 you summar
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_pr
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
>
25 matches
Mail list logo
