[cvsnt] mismatch in rcs file between deltas and deltatexts -- fixed

Garyl Erickson garyl at veicon.com
Wed Apr 18 21:05:19 BST 2007


Community technical support mailing list was retired 2010 and replaced with a professional technical support team. For assistance please contact: Pre-sales Technical support via email to sales@march-hare.com.


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 support at march-hare.com 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


More information about the cvsnt mailing list
Download the latest CVSNT, TortosieCVS, WinCVS etc. for Windows 8 etc.
@CVSNT on Twitter   CVSNT on Facebook