We have a setup (Windows, *nix clients to the same repository) similar to what Gianni describes below. Our windows clients use winCVS. When a file (say Install.c) is removed and subsequently added back as say install.c, the Install.c,v remains in the Attic while there is a corrupted install.c,v in the respository directory which cause the assert failure which in turn fails the commit. To recover from this we have to do repository surgery - remove the corrupted file, rename the Attic file to say install.c,v and then re-commit - not nice.
This error does not occur when using say *nix clients because of case sensitivity reasons.
The question is where do I file this bug ?
Thanks,
-Prabhu
-----Original Message-----
From: Gianni Mariani [mailto:[EMAIL PROTECTED]]
Sent: Saturday, October 06, 2001 9:53 AM
To: '[EMAIL PROTECTED]'
Subject: hash.c:312 - abort on commit
cvs 1.11p1
I'm not sure exactly how this state came to be, but it sure is annoying.
The repository is accessed by both Windows and Linux boxes. So, we have
a policy that all file names be lower case only. This avoids problems
with ambiguity in windows land.
So someone checked in a file "Installer.h", cvs remove'd it then
attempted to add and commit "installer.h" which resulted in an assert
failure at hash.c:312.
This is because the file did not exist but somehow it was assumed to
exist - very strange.
So, now when I try to commit installer.h into this directory from
anywhere it fails this assert().
This is a major bug.
Anyhow, I detected a corrupted installer.h,v in the repository.
Removing this seems to fix everything.
G
_______________________________________________
Info-cvs mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/info-cvs
