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.
> > If you use the right API, you don't have that limiation anymore. > Yes that is already discussed in the bug that Stefan linked to. It's the Microsoft C Runtime (CRT) that is the problem. It is our intention to address this - certainly in the server, but when we look at the client we also need to look at TortoiseCVS, WinCVS and WinMerge at a minimum to ensure that we don't simply move the error from one component to another. TortoiseCVS and WinMerge are unlikely to require as many changes as CVSNT. If we are the ones to code it then the timeframe will come down to funding - if a customer with 500 licenses raises this as an issue it's likely to be prioritised. I'd be very interested to know in 'real world' cases how widespread this issue is and in particular: 1. is there a particular toolchain more likely to create this (eg: Eclipse/Java) 2. is this more common as a client or server issue (anecdotal evidence indicates it's more often a client issue) 3. is this also a problem in svn/git on windows? Is it already being addressed, or unlikely to be addressed? 4. can we determine if switching API's will have other positive or negative effects - eg: performance, compatibility with anivirus, etc etc 5. are we certain that MS are not going to address this in the CRT any time soon (MSVC 2010)? 6. should we combine this effort with a move towards asynchronous I/O (threaded) - I'm thinking more the client here than the server, but it's applicable to both. Implementing asynchronous I/O would mean that CVSNT would no longer stop on the 'first' error - ie: 'cvs up a b c d' - if 'b' fails then currently CVSNT stops leaving a updated but not c or d - but with asynchronous IO both a and c could be updated before b fails and d aborted 7. does anyone know if the Intel c++ compiler includes its own crt - and if so would be resolved (or another windows c/c++ compiler but not ming or gcc which are not viable) I've replaced the CRT stream library functions once before (many years ago) with another March Hare product (UD6) that was originally written for HPUX 10 and then ported to windows. After using the MS CRT for the first draft the performance was terrible, so we basically created our own stream I/O library for windows. However re-using this code in CVSNT would require investigating some licensing issues and also some design decisions that made sense for UD6 that probably doesn't make sense for CVSNT. Regards, Arthur Barrett