Paul Sander wrote:
On Sep 11, 2008, at 10:39 AM, Ittay Dror wrote:
Quite the opposite, YOU told cvs (via -kb) not to change the file,
and it obeyed, i.e., you added the file with -kb and then committed
it from MS, and on MS the file contained "/bin/bash^M", and because
of the -kb, cvs on Linux gave you EXACTLY the file committed on the
MS machine which contains "/bin/bash^M"
what happened is this:
- there was no -kb
- a developer checks out the source tree and works with it, making
some changes to .c files
- not touching the file in question. the file is a startup script
for a daemon
- the build is ok on windows, so now he wants to check it is ok on linux
- we don't want him to commit in order to test.
- so, he mounts the source tree from a linux machine and runs the build
- this copies the file to the output of the build
- he wants to test the daemon, so he runs the startup script (the
file in question)
--> this fails. the file was checked out in windows, so now it has ^M
This sounds to me like it's not a CVS problem at all. The checkout to
the Windows machine has the correct line endings for the platform.
But then the sandbox is mounted from a different architecture using
different line-ending conventions, the text files are interpreted
as-is, and they break. It's unreasonable to assume that such an
arrangement will work at all because the tools on the different
platforms just don't interoperate well in this way (and rightly so).
The build on the Linux box should account for line endings if the
source tree is mounted from Windows. Or the method used to copy the
source tree from Windows to Linux could do the translation. Or you
could check out on Linux and mount the Linux sandbox on Windows for
testing, if Windows is more forgiving than Linux with regard to line
endings. Or you could commit to a work branch and let CVS do the
conversion while checking out into a second sandbox on Linux, and
merge back to the parent branch after testing. Or you could reduce
your aversion to committing unfinished code.
why does a tool like CVS take active action in changing a file for me
and then i have to work around it? if cvs had done nothing, well, ok.
but it does the action that causes my chosen workflow to break, so now i
have to take a counter action?
checking a file as-is should have been the default, and changing its
line endings should have been a nice feature to enable.
ittay
--
--
Ittay Dror <[EMAIL PROTECTED]>
