Bernard Blackham wrote on 23 April 2008 18:08:
> Why doesn't the Cygwin SVN build simply just #define WIN32 (or
> whatever it takes) so the code which is _already in SVN_ to work
> around this problem is actually used to fix the issue? I have not
> seen anyone give a reason as to why this shouldn't be done. (If
> there is, please feel free to flame me :)
I don't know in this specific case, but in the general case: nobody else is
reporting having this problem apart from you. There are millions of other
programs out there that aren't cygwin, and it seems Just Plain Wrong to twist
and contort cygwin until it's bent completely out of shape trying to fix other
people's bug in other people's software. (Historically, that's one of the
prime reasons why the windows OS itself is such a godawful mess....)
Simply defining WIN32, btw, will not work. It will bring in all sorts of
code that assumes MSVCRT functions are available, and just break the .. (oh,
hang on, I see Brian has just addressed this point, so I'll leave off there).
> I work with a repository of about 2GB and nearly a hundred thousand
> files. I have never been able to check this out with Cygwin SVN
> without it failing - company policy does not allow disabling of
> virus checkers (as does the lack of admin rights).
Again; if it is your company policy to force you to use buggy AV software
that breaks the vital tools you need to perform your work, then your company's
policy is bad and wrong, and nobody is particuarly inclined to try and work
around it in cygwin, potentially impairing the operation of cygwin for the
everybody-else-in-the-world who does /not/ work for your company.
> It would be much easier if the SVN
> binary in Cygwin would DTRT in the first place.
It DOES do absolutely "the right thing", and is prevented from success by
external force majeure. All cygwin does is open, read, write, and close
files. Any system on which those fundamental operations can fail owing to the
interference of another application is fundamentally broken, and it is not
cygwin's fault for in any way not "doing the right thing".
> Is there a showstopping reason why this can't be done? I would be
> more than happy to test it out :)
Of course there is no reason why it is impossible in theory, but there may
be engineering reasons such as performance impact why it is not desirable in
practice. SVN is an open source project like any other, so if you want this
changed, your best bet is to send a patch upstream to the responsible
maintainers. It would greatly strengthen the argument for inclusion of the
patch if you accompanied it with timings of testruns that show it does not
cause any significant performance degradation - not, of course, when compared
with the version that can't fully run under your buggy antivirus, but when
compared with the unpatched version running under no antivirus, or when
comparing the two as run under a different antivirus; you can't justify
causing a slowdown for everybody by pointing to your one broken machine and
saying it's not slower on that, for example.
cheers,
DaveK
--
Can't think of a witty .sigline today....
--
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Problem reports: http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ: http://cygwin.com/faq/
