From: "Tim Van Holder" <tim DOT van DOT holder AT pandora DOT be>
To: <djgpp-workers AT delorie DOT com>
Subject: RE: MS-DOS path support in CVS
Date: Tue, 12 Dec 2000 18:36:24 +0100
Message-ID: <NBBBIOJKJBNCHJBEKHLOMEEJCCAA.tim.van.holder@pandora.be>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
Importance: Normal
In-Reply-To: <Pine.SUN.3.91.1001212112152.24447H-100000@is>
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by delorie.com id MAA01654
Reply-To: djgpp-workers AT delorie DOT com
Errors-To: nobody AT delorie DOT com
X-Mailing-List: djgpp-workers AT delorie DOT com
X-Unsubscribes-To: listserv AT delorie DOT com
Precedence: bulk

> I only mentioned other ports because, when I suggested to replace a
> colon with a semi-colon, you said that compatibility with other CVS
> ports will take a blow.
Point taken.

> I don't see how text file format is a problem: I expect CVS either to
> use text-mode reads or remove CR before LF after reading the files.
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.
I guess the only thing I'd want is to make sure that CVSes print
sensible error messages if used on an incompatible sandbox.

> If compatibility with other ports _is_ important, converting the
> result of _fixpath to use backslashes is a trivial loop, so it would
> be easy to add.
True. 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?).

> ??? _fixpath does not resolve SUBST and JOIN.  Perhaps you were
> thinking about _truepath, which I didn't suggest for this very
> reason (and also because _truepath can return a UNC).
My bad. In that case, using /dev/ internally, and fixpathing the root
whenever its shown may be an elegant workaround.

> If you find the drive support too painful to add, I'm willing to 
> volunteer to add it and send you patches.
No need - I'm quite willing to do it - I just don't want to go
through the trouble if there's no real need to do it.
I'll see where the internal-/dev-external-fixpath(/dev) changes
take me.

To Be Continued