Mail Archives: djgpp-workers/2000/12/16/04:40:57
> [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.
- Raw text -