[cvsnt] Corrupt history file

[Chuck Kirschman]

I send Arthur sections of the history file, and he has already committed 
a likely fix.  I have not tried it yet because I don't have a QA 
environment, but when I get a chance I'll build a custom version of 
2.5.3.2382 with his fix for testing.  Thanks Arthur!


As for Auditing, Bo posted this great link:
	http://web.telia.com/~u86216177/CVSNTAuditing.html

It's very helpful, but includes things like:
- Whenever a new file is added on a branch and committed this is not 
recorded in the auditing database. The bug has been reported but no word 
has come from the developer that it is fixed or will be fixed.

- "HistoryLog" is written in a way I don't yet fully understand. There 
seems to be two records for each file committed.

The former is bad from the standpoint of what I need to do with history, 
and the latter would greatly increase the disk space requirements.  My 
history files are on the order of gigabytes per year already, and would 
likely expand when put in a database.  Multiply that by 100 
repositories, which you'd certainly want to put on the same database 
server.  Although disk space is cheap, high-availability server disk 
space is not.


And below Arthur says in response to my question "what happens if the 
connection to the database server is broken?  Does it log locally?"
- No audit - no changes to the repository - that is what an audit is 
supposed to do.

I interpret this to mean that if the database server goes down or even 
just the network connection to it, that means CVS is completely down for 
all of my servers.  That's a fairly crippling limitation.

Also, I'm not sure what the Audit Settings logging options mean.  I'm 
pretty sure I wouldn't want checkin differences, but what does Sessions 
mean?  What about History - isn't that what this is supposed to be? 
Unfortunately Bo's document doesn't cover the details, and I have been 
unable to find any explanation in the docs or news group.  I would love 
to turn off all the clutter about every update since I've yet to have 
need of that information.

Thanks
chuck



Arthur Barrett wrote:
> Chuck,
> 
> 
>>Corruption seems to occur every few days. 
> 
> 
> If it's occuring that often - enable server side tracing and try and capture it occuring with a trace, eg:
> cvs -ttt rlog
> 
> 
>> Or I can revise my script to supply a few 
>>lines on either side if that's what you need.
> 
> 
> Yes thanks.
> 
> 
>>Going to the database approach seemed unwise after 
>>reading on the news group all of Bo's problems with it.  
> 
> 
> There are no known problems with Audit.  
> 
> Referring to "problems" without particular quotes (preferably the URL's of the messages) is not very helpful.
> 
> If you want to personally check with Bo go right ahead.  Audit is more reliable than history ever was...
> 
> 
>>what happens if the connection to the database 
>>server is broken?  Does it log locally?
> 
> 
> No audit - no changes to the repository - that is what an audit is supposed to do.  
> 
> The overhead of the audit database will depend on which database you use.  SQLite for instance is probably the lightest, but something like MSSQL is more "commercial".
> 
> The "problem" (once again) with history is that if there is any problem in writing it then the server just blindly continues.  So technically speaking the corruption you are seeing is the defined behaviour.  The server is having some problem writing and it just continues.  The fact it has just began occuring could be to do with the size of the history file, or some other factor (including the CVSNT code).
> 
> 
>>I'm not adverse to going with a database, but 
>>with 100 repositories on 8 servers and 100 GB 
>>of source with very active histories, it's a 
>>substantial change.  
> 
> 
> It's completely off topic - but if your system is business critical and you need to mitigate your risks then I strongly suggest paying the vendor/developer for support (and yes I do work for the vendor/developer of CVSNT).
> 
> Regards,
> 
> 
> Arthur
> 
>