Community technical support mailing list was retired 2010 and replaced with a professional technical support team. For assistance please contact: Pre-sales Technical support via email to sales@march-hare.com.
"Arthur Barrett" <arthur.barrett at march-hare.com> wrote in message news:foqn1a$f9j$1 at paris.nodomain.org... >> I guess there was never any part of the CVS design to have the cvs.exe >> listen to the port in the foreground? (kind of like a non-spawned daemon >> in linux). That would avoid the need for the cvsservice wrapper while >> devleopping / testing... > > I think that is what the "fork" protocol is for... Right - fork is normally what will spawn a seperate process, but allows you to grab it's STDIN/OUT filedescriptors and/or create any other pipes to/from the forked process. But in this case, I'm looking to avoid the fork. cvsservice spawns the child process using CreateProcessW, but I don't know if there is a way to "reuse" the same process over and over of cvs.exe. It doesn't seem like it however.. > I pretty much always just stick TRACE statements in wherever I want to > debug, build a release build, install on a testing box and go from there. > It's (much) slower that Tony's way, but reflects the differences in the > type of work we are each doing - Tony is doing major feature work and I'm > doing the odd bug fix and small feature. Fair enough. And although that does work, it is usually of service when you know the code already. However, when you are in my shoes, trying to understand this mountain of code in an unfamiliar editor, stepping through with a debugger is invaluable. Trace statements would take way to long to follow. As an aside, for what it's worth, hopefully you will take this as constructive criticism from a new guy looking at the cvs code for the first time; personally, I find the code severely lacking comments. I know cvs is something that has pretty much mushroomed into what it is today, but I find it difficult and tedious to understand how the logic is working and what it is trying to accomplish. The few areas that do have comments significantly improve and accelerate the process. I hope that given that EVS is a brand new application, you have given yourselves enough time to document it in order to make it easier to maintain and develop down the road. Thanks, Eric