[cvsnt] Corrupt history file
arthur.barrett at march-hare.com
Tue Nov 21 02:36:32 GMT 2006
> 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.
> 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).
More information about the cvsnt