Aaron Mulder wrote:
Daniel,
There another angle to this that I think you're missing. If a
Windows user submits a zip file patch and a Linux committer applies it,
the line endings are still likely to come out screwy despite having a
properly configured CVS client.
i am not missing anything. i was just assuming that most of the
CRLF <-> LF error will occure because of a missconfigured cygwin
installation. the point is that you can screw up CVS in many ways
and that this discussion exists since CVS was introduced.
a common source for CRLF <-> LF error are for example Samba shares:
1) one checks out a CVS module under Windows to his home drive
which is physically a Samba share. now she opens a SSH/Telnet
session and edits the just checked out files using emacs for
example. finally she does a commit on that particular UNIX system.
i guess you know what will happen ...
and believe me i saw lots of software developers checking out
CVS modules to a Samba shares and editing files within that
module on UNIX.
so which script will prevent you from people that are switching
between UNIX-Windows all the time while working on a CVS module?
what is my point?
i think that on should try to control the machine as much as possible
if you hand over the control to a script (such as the one in ...
-> CVSROOT/commitinfo
... you will likely introduce other error sources. for example how can
you assume that if one hands you over a ZIP file that she created that
ZIP file on a UNIX system. in those cases you will always _need_ to
double check (additionally it would help to require patch submitter
to state whether they created the patch while working on UNIX/Windows).
regards
daniel s. haischt
--
