[cvsnt] Corrupt history file
Chuck.Kirschman at Nosp_am.bentley.com
Wed Nov 22 15:50:35 GMT 2006
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
188.8.131.522 with his fix for testing. Thanks Arthur!
As for Auditing, Bo posted this great link:
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.
Arthur Barrett wrote:
>>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
> 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