From: "Tim Van Holder" To: Subject: RE: MS-DOS path support in CVS Date: Mon, 11 Dec 2000 22:32:10 +0100 Message-ID: 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) In-reply-to: <7458-Mon11Dec2000220128+0200-eliz@is.elta.co.il> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Content-Transfer-Encoding: 8bit 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 Precedence: bulk > > 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?