Re: RCS Error

[Garyl Erickson]

Diego,

You can search for the \x3c (hex 3c?) in the rcs ,v file, which may give you a clue as to what the problem is. The ,v file format is fairly straightforward. Examine a few and you'll figure out the syntax. If you want to go to the trouble to find out exactly where the problem is, you can do a brute force approach. Manually cut revisions out of the ,v file (make a backup first!) using a binary reduction method: cut out half the revisions (and update the pointers to the last version, etc.); if it still has a problem, cut out half of what's left. Repeat until you find the section that caused the problem. I did this once when I had a somewhat similar problem shown up by the log command, see the cvsnt emails attached below.

Good luck,
Garyl


address@hidden wrote:

Hi all,

 Im on a effort to migrate a lot of projects from Clear Case to CVS. Some
of these projects were migrated well with no problems. Some of them
needed to be repaired manually and after that worked well.

 Most of these projects have a average number of files about 700 with an
average number of revisions for each file about 30.

 Im now in charge with a Bigger project of 3700 files and about 60
revisions for each file. Most of the RCS files generated are working
well. But some of them are not, and CVS give up when Im tryng to analyse
with "log" command or retireve a older revision.

 A example of what is going on is this message:

 -f [log aborted]: unrecognized operation '\x3c' in
/opt/cvs/rep/somefile.html,v

 This code '\x3c' varies for each "corrupted/misfunctioning" file.  This
occurs for some files, and I dont know what could be happening. Does
someone had experienced a problem like that before?

Best Regards! Thanks for ALL!

Diego.

---

Subject:	[cvsnt] mismatch in rcs file between deltas and deltatexts
Date:	Fri, 06 Apr 2007 09:25:08 -0700
From:	Garyl Erickson <address@hidden>
Organization:	Veicon Technology, Inc.
To:	address@hidden

I have one file in my repository that I can't run cvs log on. It fails
on most cvs log commands, except for -t and -h (with or without -N),
with the following message: [log aborted]: mismatch in rcs file
source-file-pathname,v between deltas and deltatexts").

I have no problems with any other CVS commands I've tried on that file.
I can check out every available revision of it, do diffs between
revisions, etc., so the deltas in the RCS file seem to be (mostly?) ok,
despite the error message. I've also looked at the ,v file in some
detail and compared it to others. I don't claim to be an expert but it
seems to match the pattern of the others. One thing that's different
than most is this file was renamed and moved to a different directory at
some point and the initial revision is 1.26. But starting a file with a
specific revision number should work, and I have others that do that
work fine. The earliest revision found in the ,v has a blank next field.

Using -ttttttt indicated the last sub logged was RCS_fully_parse(),
which, after a very cursory look, seems to output the mismatch error if
it can't find a particular version it's looking for (is that right?)

Are there any tools to analyze the ,v file in more detail or to repair it?

Any other ideas how to debug or fix this?

Thanks,
Garyl


P.S. I'm running CVSNT 2.5.03 (Scorpio) Build 2151 on Windows Server 2000.
_______________________________________________
cvsnt mailing list
address@hidden
http://www.cvsnt.org/cgi-bin/mailman/listinfo/cvsnt

---

Subject:	Re: [cvsnt] mismatch in rcs file between deltas and deltatexts -- fixed
Date:	Wed, 18 Apr 2007 13:05:19 -0700
From:	Garyl Erickson <address@hidden>
Organization:	Veicon Technology, Inc.
To:	address@hidden
References:	<address@hidden>

This was still bugging me so I finally resorted to brute force to figure 
out what was wrong with the ,v file. I manually cut revisions out of the 
,v file (using a binary reduction method: cut out half the revisions; if 
it still has a problem, cut out half of what's left, etc.) until I found 
the section that caused the problem. It was a log and text (diff) 
section for rev 1.84.2.1. This branch was not mentioned in the symbols 
section at the top of the file, i.e., there was no tag for the branch 
1.84.0.2.

After looking at other files in the repository, I added a symbol for the 
branch at the right place:  v2-patches:1.84.0.2, but I still couldn't 
log the file. Since the change in the rev 1.84.2.1 file on the branch 
was also on the trunk, and there was no mention of this branch in a 
branch field in this file (meaning no revisions on this branch were 
otherwise known), and there didn't appear to be any revisions on that 
branch tagged in other files, and it's old (past support), and there was 
no mention of anything related in other documentation, I just deleted 
the anomalous log and text section. This cleared up the logging problem. 
Whew!

Of course, the question still remains as to how this happened. It's as 
if someone attempted to remove a branch (perhaps manually?), but didn't 
completely succeed.

More comments below...

Garyl


Arthur Barrett wrote:
> Garyl
>> One thing that's different than most is this 
>> file was renamed and moved to a different directory 
>> at some point 
>>     
> Was that with "cvs rename" ?
>   
Probably not, as I don't think we were aware of the cvs rename command. 
Does it support a directory change? It was most likely done using the 
"normal" procedure using copy /old-filename //new-filename, /cvs add 
/new-filename/, cvs remove /old-filename/, and cvs ci -r/rev/. Both the 
old (dead) and new files exist and I can run cvs log on the old 
filename. The comment for its last revision says it was renamed to the 
new filename. According to the ,v file for the new file, its first 
revision is the same as the last revision of the old filename. Both the 
last revision of the old file and the first revision of the new file 
have the same comment and the same commitid.
>> and the initial revision is 1.26. But starting a 
>> file with a specific revision number should work
>>     
> Yes it *should* but it is not recommended and probably not tested for
> years.
>   
FYI, it seems to work fine for other files in this repository, and now 
this one, once the vestiges of the deleted branch were removed.
>> Are there any tools to analyze the ,v file in 
>> more detail or to repair it?
>>     
> You've done it already - "cvs log" is the way to analyze the ,v file...
>> P.S. I'm running CVSNT 2.5.03 (Scorpio) Build 2151 
>> on Windows Server 2000.
>>     
> If possible please upgrade to 2.5.03.2382 - but it probably wont fix
> this...
>
> If it still occurs - send the RCS file to address@hidden and we
> will file it and put it on the bug list.  We won't look at it for a
> while - but we'll never look at it unless we have a test set...
>
> Regards,
>
>
> Arthur
_______________________________________________
cvsnt mailing list
address@hidden
http://www.cvsnt.org/cgi-bin/mailman/listinfo/cvsnt