Re: changes to cvsgui_protocol/AppGlue that might be interesting for gCvs

Jens,

>(1) catch stdio output from the cvs process:

We will aim to support both cvsgui protocol and the "direct" output
interception. We shall control the type of interception simply by adding the
flag in



----- Original Message ----- 
From: Jens Miltner
To: [email protected]
Sent: Monday, February 09, 2004 10:13
Subject: [cvsgui-dev] changes to cvsgui_protocol/AppGlue that might be
interesting for gCvs


Hi,

I recently made two changes to the cvsgui_protocol / AppGlue sources
for MacCvs, that I think might also apply for gCvs (however, they're
conditionalized for MacCvs only currently):

(1) catch stdio output from the cvs process: some of the information
printed by cvs and it's child processes (e.g. ssh) are done using
regular printf and thus ended up in the system console instead of
MacCvs console. I've added some code to create pipes for stdout and
stderr and insert the information written there into our cvsconsole
stream.
While in theory, this might cause partial lines written through stdout
to be mixed up with partial lines written through the cvsgui_wire
protocol, in real life, I haven't yet seen this - I think usually, the
information is separated enough so it doesn't end up intermixed.
I assume that gCvs should have the same problems, as the runtime
environments w.r.t. launching the cvs process are similar (both unix
based), so you may want to check whether this modification also applies
to gCvs.
[One test case would be to try to access a remote ssh repository
without having set up an ssh-agent that can deliver the ssh key. In
that case, the ssh errors ended up in the system console on MacCvs, but
the MacCvs log contained the line "error while connecting (see messages
above)" (or similar), but the cited "messages above" actually ended up
in the system console and thus were rather hard to discover]

(2) When the cvs process was terminated, MacCvs never ever closed the
pipes it created to communicate with the cvs process. This caused
MacCvs to eventually run out of file descriptors after it had performed
quite a few cvs operations. I fixed this (again conditionalized for
MacCvs only) by making sure the cvs process information is properly
destroyed after cvs finished. Again, from what I could read from the
code, I assume the same problem occurs in gCvs.
The fix for MacCvs is a call to cvs_process_destroy() after we've
waited for the cvs process to terminate in launchCvs.


</jum>

[Non-text portions of this message have been removed]




Yahoo! Groups Links

To visit your group on the web, go to:
http://groups.yahoo.com/group/cvsgui-dev/

To unsubscribe from this group, send an email to:
[email protected]

Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.


 
Yahoo! Groups Links

<*> To visit your group on the web, go to:
     http://groups.yahoo.com/group/cvsgui-dev/

<*> To unsubscribe from this group, send an email to:
     [email protected]

<*> Your use of Yahoo! Groups is subject to:
     http://docs.yahoo.com/info/terms/