Re: Two head revisions?

[Derek R. Price]

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
<derek@ximbiot.com>