Mail Archives: djgpp-workers/2000/12/13/13:16:59
> > 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.
> > The backslash thing wasn't the problem; the requirement of the
> > :local: prefix might be (i.e. should we require/prepend a :local:
> > prefix just because the Win32 CVS does?).
> I'm not sure. Perhaps I don't really understand the issue. Can you
> elaborate a bit?
You can specify an access method with your CVSROOT. :local: means access
the repository directly; this is also the default as long as the CVSROOT
does _not_ contain a ':', in that case :ext: or :server: is assumed
(so /usr/local/cvs wold be :local: and machine:/usr/local/cvs would be
:ext: or :server:). The NT port therefore requires :local: so DOS paths
won't get mistaken for network paths. My previous CVS port (1.9/1.10)
handled DOS path specially altogether.
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?
- Raw text -