Kuros Yalpani wrote:
> Thanks Derek. Please glance at the trace that I included below. I do a 'cvs commit'
> there after a 'cvs remove <oldfile>' and yet it appears that <oldfile> still exists
> in the "Entries" file. Is this the correct behaviour?
After further examination, I think this is the correct behavior, though <oldfile>
actually isn't in the CVS/Entries file after a remove and commit. The basic logic
seems to be that CVS is providing you a case insensitive view of what exists on the
server - basically making the server look like a case insensitive file system with
occasional errors (e.g. two files with the "same" name), so you can remain in your
case insensitive world ideally without ever really knowing that the server's world is
case sensitive. for example, 'cvs co module/FILE1' could check out something named
module/file1 on the server, or a 'cvs add file1' will find FILE1 and figure you're
re-adding it.
There might be an argument for making the view of the server more selective, but I can
see reasons you wouldn't want that.
Incidentally, you turned me on to a bug in CVS 1.11 and handling case insensitive
files in conjunction with 'cvs add'. The test case you gave actually reports an
internal error from a 1.11 server. I think I'm 2/3 or so of the way to a fix (it no
longer aborts the commit) but I ran into a slight snag that is probably going to
require an hour or two of reading code to understand and I'm trying to finish up for
the weekend, so you might see the fix for _that_ next week sometime.
Derek
--
Derek Price CVS Solutions Architect ( http://CVSHome.org )
mailto:[EMAIL PROTECTED] OpenAvenue ( http://OpenAvenue.com )
--
Smash forehead on keyboard to continue.
_______________________________________________
Bug-cvs mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/bug-cvs
