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:	Mon, 11 Dec 2000 22:32:10 +0100
Message-ID:	<NBBBIOJKJBNCHJBEKHLOIEEHCCAA.tim.van.holder@pandora.be>
MIME-Version:	1.0
X-Priority:	3 (Normal)
X-MSMail-Priority:	Normal
X-Mailer:	Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
In-reply-to:	<7458-Mon11Dec2000220128+0200-eliz@is.elta.co.il>
Importance:	Normal
X-MimeOLE:	Produced By Microsoft MimeOLE V5.50.4133.2400
X-MIME-Autoconverted:	from quoted-printable to 8bit by delorie.com id QAA07764
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

> > This would have the side effect that
> >  a) Any messages from CVS regarding the root would
> >     include the /dev-style path, and
> >  b) CVS/Root will contain the /dev-style path for newly
> >     made sandboxes.
> Printing messages in /dev-style might confuse users.  As for CVS/Root
> files, using /dev there means that other versions of CVS will not be
> able to use the same CVS tree.
I know.
In the case of 'other versions' though, that would mainly be either
the Win32 or the Linux version. The Win32 version could be seen as
inconsequential; once we have proper networking under Win32, the
DJGPP version could replace it (for us DJGPP users anyway). As for the
Linux port, it would be easy enough to set up symlinks to simulate
/de-style paths (/dev/C -> /mnt/dosdrive).
I agree that this isn't perfect, but storing the dos path would also
break other CVSes (Linux won't support it, and I believe the NT
version requires it to be ':local:D:\ospath'). In any case, sharing
a sandbox between CVS versions will usually lead to trouble anyway
due to text file conventions, so inter-CVS compatibility should not
be a major factor for the DJGPP version; if it can be preserved: fine,
if not, that's not too bad (IMO, anyway).

> Is it possible to plumb these two holes by calling _fixpath on the
> /dev-style filename just before you print a message or write the path
> to a file?  Perhaps CVS uses a small number of special functions to do
> those chores; if so, you could change only those few functions.
That would be a solution, but _fixpath does too much. Some people
tend to use SUBSTed drives with DJGPP and/or CVS, and fixpath would
resolve those as well (leading to equal, if not more, confusion).
And to always turn /dev/e/foo into E:\foo (whether manually, or through
_fixpath) would be equally confusing to people who actually specified a
/dev-style path.

So either I try to add proper DOS path support everywhere, with a
potential for subtle breakages, but with paths shown the way they were
given, or I use this workaround, which would keep most of CVS intact,
but has the abovementioned drawbacks.
Maybe DJ could cast the deciding vote?

- Raw text -