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 email@example.com.
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)