[cvsnt] Workaround for 260 char limitation?
arthur.barrett at march-hare.com
Thu Nov 5 22:32:11 GMT 2009
> 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:
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.
More information about the cvsnt