Jim Hyslop wrote: > Could there be some hidden characters (e.g. embedded backspaces)?
Waiting on the tape backup retrieval... > The usual troubleshooting questions - does the problem manifest itself > only the one file, or on multiple files? If multiple files, is there any > common attribute of those files? Only the one file has been discovered so far. > What version of the client & server? A slightly hacked 1.11.21, but using your suggestion I can duplicate the problem using 1.12.12 and 1.11 development, so I don't think it is the hacking causing the problem. > access method? mounting points (i.e. Samba, NFS, local, etc.)? I believe it is local, but it may be an NFS netapp with a local LockDir or something like that. I requested they refresh my memory. > Hmmm... do you have access to any backups, which might show what the > file really did look like after Jane's commit and before Joe's commit? I don't know. I've put in requests for the version of the archive prior to the last commit and the version previous to that. > So, just to make sure I understand the problem correctly: here, we would > expect to see something like: > > 1.5 > date YYYY.MM.DD.hh.mm.ss; author joeshcmoe; state Exp; > branches; > next 1.4; > > followed by the revision data for Jane, for rev 1.4, right? Yes. > Here's a hypothesis: maybe before Joe's commit the revision metadata for > rev 1.4 was missing or corrupted, so CVS thought the most recent version > was 1.3, and ignored the existing 1.4 revision entry. Okay, thanks for the suggestion. I have now verified two interesting things: 1. If I delete the revision 1.4 metadata in a file with 4 revisions, and correct the "head: 1.4" tag in the header to read "head: 1.3", then a commit duplicates the behavior I have described here. (deleting the revision metadata without updating the head tag, I get an error checking out) 2. If I only update the "head" tag to point to 1.3 and commit, the behavior _almost_ duplicates the behavior I have described here, but leaves the 1.4 revision metadata unmodified. Both of these feel like bugs, even if they only crop up in the presence of previous file corruption and I will come up with a patch to detect the corruption instead of corrupting the file further. Now the question remains how both the revision metadata and the "head" tag in the header could be corrupted simultaneously (presumably by the previous commit) without munging the revision texts or the rest of the metadata. This looks more like a typical lock failure, but I'm still having trouble coming up with the exact scenario to reproduce the code path and corruption. Any ideas I might be able to test before I get a copy of the original archive? Thanks, Derek -- Derek R. Price CVS Solutions Architect Ximbiot <http://ximbiot.com> v: +1 248.835.1260 f: +1 248.835.1263 <[EMAIL PROTECTED]> _______________________________________________ Bug-cvs mailing list [email protected] http://lists.nongnu.org/mailman/listinfo/bug-cvs
