Mail Archives: djgpp-workers/2000/12/14/13:04:46
> 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:
> [snip]
I agree.
> (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?
Not really. Although I'd use binary mode for everything (including
the CVS/* files). Besides allowing for the degenerate case where
one of these has an embedded CR, it also corresponds better to what
WinCVS does. If it has created a CRLF CVS/Root file, it will also
have read/written all the other (non-binary) files in the sandbox
in text mode. Basically, if people want to use a DJGPP CVS sandbox
together with WinCVS, they'll have to enable WinCVS' "Use Unix LF"
option (and use "--lf" if they also use its command-line CVS).
> 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:
> [snip]
I'll start by setting _fmode to O_BINARY and seeing if that works
reliably. The only issue there might be when the server sends a
diff.
> In my experience, patches like the above are generally accepted by GNU
> maintainers without any problems, because they avoid OS-specific
> #ifdef's.
Yes, but the CVS maintainers seem disinclined to accept DOS-specific
patches anyway - they only accept stuff that is related to CVS on
the platforms on which they use it. DOS isn't one of them. I'll be
happy if we end up with a CVS for DJGPP that works properly and has
client support. Whether it becomes part of the official sources
doesn't really matter so much.
> 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.
Good. I'll see where this takes me.
- Raw text -