From: "Tim Van Holder" To: Subject: RE: MS-DOS path support in CVS Date: Sat, 16 Dec 2000 10:43:58 +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: <20001215120808.A24180@kendall.sfbr.org> 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 EAA21172 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 > [snip] > Anyway, it seems that DOS support for pre-cvs-1.10 shouldn't require > any RCS changes; however, I don't know about cvs-1.10 (-1.11) that > use their own internal RCS routines. OK - I'll check if CVS's RCS routines allow for '-x'-style behaviour. In fact, there probably won't be a real problem if files in the repository retain their original name, provided that a) No RCS-oriented tools (that don't support -x) need access there (e.g. some scripts might) b) The user is smart enough not to be confused by this. > Erik also worried about long filenames, but I think many of the > LFN->SFN issues solve themselves, provided the LFN contains no > `illegal' characters (like [.,]) and the 8.3 truncations are unique > (as most or all of them seem to be). E.g., reading/writing to > `CVS/Entries.Backup' under DJGPP automatically generates the 8.3 > file `CVS/Entries.bac', so the LFN isn't really a problem. This is NOT a minor issue, especially if also using Windows. Binutils, for example has many files that share the first 8 characters (foobar32.c and foobar32-mips.c). If the longer of the two gets created first, it will get foobar32.c as short name. Meaning that foobar32.c can not be added to the repository anymore. SFN's are a nightmare here. Also, there is the case insensitivity. CVS already handles this pretty well - if there is a CVS-controlled file called FOO, and you then commit a file called Foo (a typical NT problem), it will commit it as FOO. And if you try to add Foo, it will complain accordingly. This is handled pretty cleanly (there's a filename_cmp function for this). I have noticed a serious bug with this though: if you add a file Foo, and a file called FOO is in the Attic (i.e. it was in CVS but has been removed at some point), the server will abort (probably because it had seen the match though filename_cmp, but when it went to retrieve the actual file, it used Attic/Foo,v, resulting in a problem), leaving a file Foo,v on the server containing only an RCS header. At that point, you need access to the server to remove the file, or you're screwed. > Files like `.cvsignore' *do* need special attention: > .cvsignore -> _cvsignore -> _cvsigno Right. And the .#foobar style temporary backup files will also need work. > Erik moved ,[pt] files to CVS/P/ and CVS/T Again: good, unless some script/tool expects the normal name. > Erik renamed lock files from `#cvs.[rwt]fl.XXXXX' to `XXXXX.[rwt]fl'. Acceptable. > He also renameed #cvs.lock to #cvslock (unnecessary if it truncates > uniquely to #cvs.loc). (Maybe a LOCK/ subdirectory would be useful?) I don't think the subdir is acceptable, as it creates another potential race condition in the locking code (I think). The rename to #cvslock could indeed be unnecessary, but would be a problem either. I guess the biggest problem here is that if a repository is used in both SFN and LFN environment, all sorts of bad things can happen. If an LFN file is removed from CVS in an SFN environment, for example, it will lose the associated LFN (because of the move to Attic). All this just to say that the SNF/LFN issue is not so straightforward to solve, especially since you're using multiple environments at the same time. I'm disinclined to try and work this in immediately, so unless I get diffs from someone else, it'll have to wait until the next version of cvs.