Mail Archives: djgpp-workers/2000/12/14/04:54:12
On Wed, 13 Dec 2000, Tim Van Holder wrote:
> > > It uses text mode reads. This means that if a sandbox is shared
> > > between a DJGPP CVS and a Linux one, text files would get dossified(tm)
> > > frequently, causing potential trouble.
> >
> > Well, that's another problem, then. Let's take the problems one at a
> > time, okay? ;-)
> Certainly. There's no clean way around this anyway - you can do all
> reads in binary, but then you require users to use Unix-style text files.
> WinCVS has this mode in its CVS; they have a --lf option to CVS that
> causes it to use binary file accesses. This means it can safely work
> with a sandbox that originated on Linux, and has the added advantage
> that you can store both DOS and Unix text files 'as is' (i.e. without
> having to resort to -kb to make a DOS text file stay DOSsy when checked
> out on Linux).
> Perhaps incorporating that option in our CVS would be useful.
Here's my opinion on the text/binary issue in the context of CVS:
I think CVS should use binary I/O by default and have an optional
switch to use text-mode I/O. This will DTRT in most of the cases:
- checking out from a repository will preserve the EOL format of the
files as stored in the repository;
- Unix-style files stay Unix-style, DOS-style files stay DOS-style;
- no more trouble with batch files stored as text files in the
repository;
- ``strange'' files (e.g., files with an isolated CR) can be checked
in and out as text;
The only case where users will have trouble is if they work with a
repository on a Unix box for a project that should compile on Unix,
and use an editor which either (1) don't grok Unix-style EOLs, or (2)
always saves files with DOS EOLs, no matter what was their original
EOL format.
For these cases, the switch to use text-mode I/O will be the solution.
(They should use Emacs which preserves the EOL format, if they don't
want this nuisance.)
It is possible that having an environment variable that controls this
would be a good idea, to let people avoid typing the switch every
time in the problematic case I described above.
The files special to CVS (Root, Repository, etc.) should be read in
text mode (for the case where they were written by WinCVS), but
written in binary mode, since this allows the results to be shared
with Unix and GNU/Linux machines.
Do you see anything wrong with this approach?
If not, I'd suggest to set _fmode to O_BINARY somewhere in the
beginning of `main', and then use explicit "t" or O_TEXT qualifiers
in the few places where it is required. I think the changes you need
for this will be quite small, clean, and localized. To make them
even more clean, introduce a macro OPEN_TEXT on all platforms, like
this:
#include <fcntl.h>
#ifndef O_TEXT
#define O_TEXT 0
#endif
and then use it in `open' where you need text-mode I/O, like this:
int fd = open (..., ... | O_TEXT);
This will make O_TEXT a no-op on platforms such as Unix.
(A similar trick should cover the fopen case.)
In my experience, patches like the above are generally accepted by GNU
maintainers without any problems, because they avoid OS-specific
#ifdef's.
> Come to mention it, requiring users to prepend :local: to their
> CVSROOTs if they use DOS paths does not seem excessive, and it would
> probably work cleanly (I think I'd only have to adjust isabsolute()).
> What do you think, Eli? Acceptable?
I think it shouldn't be a problem to require users to use :local: if
they want it to include drive letters in CVSROOT. If this solves most
of the difficulties cleanly, I think it's a good compromise.
- Raw text -