[cvsnt] Corrupt history file

[Bo Berglund]

On Wed, 22 Nov 2006 10:50:35 -0500, Chuck Kirschman
<Chuck.Kirschman at Nosp_am.bentley.com> wrote:

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

Thanks! :-)

>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.

This has indeed been fixed in build 2382 (just checked on my test
server). So I have updated the auditing tutorial webpage to reflect
this.
Thanks for the pointer on the bug in that document.

>- "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.

I don't think that an extra record will be that bad, these records are
really only a handful of bytes each.
 
>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.

In a high volume server like this I guess that you should go with
SQLServer 2000 or 2005 or possibly Oracle, where database size is not
really an issue.

>
>
>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.

If the network fails then you are dead anyway, cvs will not work
either. But if you are having several servers depending on each other
you have better make them work all the time or at least go down
together. If Auditing is enabled then the CVSNT server enforces the
auditing before allowing cvs operations to execute, I believe. This
way nothing that happened escapes the audit.

>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.

If you are familiar with database structuring you will recognize that
sessionlog contains a log of basic data for each client command
session (hence the name).
The sessionlog.id value is stored in the other tables as a reference
to the session as commitlog.sessionid, taglog.sessionid etc.
With this there is a connection between the user (stored in
sessionlog) and the actions he has done on the repository.

These are pretty standard database techniques, even though I would
have preferred that the links were even firmer by having a foreign key
set on the sessionid column in the data tables pointing to the
sessionlog table. That way the database itself would guarantee that no
data are orphaned from its session identifier.
But apparently this causes a lot of problems considering all the
databases CVSNT supports...

HTH

/Bo
(Bo Berglund, developer in Sweden)