On Sep 11, 2008, at 1:45 PM, Ittay Dror wrote:
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?
CVS did the right thing for the client. The fact that the build
worked on Windows proves this.
Your cross-mount from Linux broke the semantics of text files during
your build on that platform. If the filesystem could tell the
difference between text and binary files and performed the conversion
instead, you wouldn't have this problem. But cross-mounts usually
don't work that way.
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?
If you check the file out on the platform for which the text is
ultimately destined, you would not have this problem. Check it out
on Windows, it works on Windows. Check it out on Linux, it works on
Linux. Under no circumstances, using CVS or not, should you expect
text files on one platform to work on the other when simply mounted
or copied bit-for-bit.
Throw in other platforms in which line-endings are CR (not CRLF as on
Windows, or LF as on Unix), and the tools are *very* unforgiving,
then you begin to see the complexity. So the tool gives text file
semantics to text files stored on the client platform, which is a
*much* simpler solution than storing the file in its original format
and making every client (or worse, the native tool set) work around it.
checking a file as-is should have been the default, and changing
its line endings should have been a nice feature to enable.
Go ahead and try it your way, and don't cry when you discover that
you actually end up in a much worse condition. You'll discover that
the problem is in your work flow, not with CVS.
This problem was solved multiple decades ago by assigning certain
semantics to text files, then applying them universally in the
various work flows where the bits cross platforms. Your choice to
declare that text files should be bit-for-bit identical on all of
your supported platforms violates this principle, and now you're
paying the price. You'll be much happier if you design your work
flow so that the cross-platform copies are made exclusively using
tools that understand text file semantics.
