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 sales@march-hare.com.
On Sun, 09 Nov 2008 11:00:02 -0200, Gerhard <gelists at gmail.com> wrote: >On Sun, 09 Nov 2008 09:19:07 +0100, Bo Berglund wrote: > >>There is one item I don't know about this that needs to be figured out >>and this is how to use the tool to get old info into the Audit >>database in a repository that has started using Audit along the way so >>some parts are already stored and some are not.... >>Clearly this must be handled so there are not afterwards double >>entries for the same items. > >For commits, that would be the commit id, I think. If it's already in >the database, it's probably safe to assume that auditing was on at the >time of the commit (or the tool has been run already). I had a look in our CVSNT repository (we started using it in January 2001) and all revisions committed from then through 2003 do not have a commitid associated to them. In January 2004 I see commitid:s starting to appear, so from then on I guess it is ok to use them. But before that what to do? I see a commit date/time down to second precision, so I could possibly generate a "pseudo-commitid" the first time a revision without a commitid is found and then check if it already exists. The commitid:s I see are of the form: '3183ffb39410000' which looks like the hex representation of a 28 bit number. Anyone knows how CVSNT generates commitid:s? Is it always a 28 nit number and if so could I create a pseudoid by using the full 32 bits and setting the first 4 to f? This would signal a commitid starting with 1111 as an import commitid. I could for example simply enumerate the pseudoid:s like this: ffff 0000 0000 0001 ffff 0000 0000 0002 ffff 0000 0000 0003 etc Another question: Is the commitid the same as the value stored into the Audit database sessionlog.sessionid column??? Is CVSNT putting meaning into the sessionid value, such as assuming it is sequential and can be used for sorting? If one uses the tool to enter old data these will get higher sessionid:s even though their timestamp is much older than existing records. If sessionid is simply a key to connect all operations for a particular client command but with no other use then it is fine and it does not matter if one fills the database with new data... >For tags and branches, it probably would be the tag/branch name. HTH /Bo (Bo Berglund, developer in Sweden)