-
I figured out that all the changes I thought I should be getting were from branched files that had their base revision deleted. After the p4spam caught up to the current changelists overnight everything was fine. Sorry for the false alarm.
2007-02-04 19:49:14 UTC in P4Spam: Perforce change review daemon
-
Oh and I'm using p4spam-1.1-rc1.
2007-02-04 09:47:17 UTC in P4Spam: Perforce change review daemon
-
I've just installed P4Spam, sending e-mails and everything is working correctly. The only problem is that I dont get any differences in the e-mails. The rest of the changelist data comes through correctly.
I'm using server Rev. P4D/LINUX26X86/2006.1/109255 (2006/10/17).
I havent noticed anything in the docs that might indicate that this is broken.
2007-02-04 09:45:01 UTC in P4Spam: Perforce change review daemon
-
Here's a fix for the padding.
hashmgr.cpp
void CHashOutput::_OutputHashBytes(UWORD8 *pHash, UINTPREF uLen)
{
UINTPREF i;
INTPREF j = 0;
RH_ASSERT(pHash != NULL);
RH_ASSERT(uLen >= 1);
if(m_bBase64 == true)
{
CBase64Codec baseCoder;
UWORD32 i32;
m_szHashBuffer[0] = 0;
i32 = RH_MAX_HASH_STRING;
baseCoder.Encode(pHash, uLen, (UWORD8 *)m_szHashBuffer...
2006-12-10 07:39:11 UTC in ReHash - Console-Based Hash Calculator
-
The padding of the hex output is reversed. The padding is added on the wrong side of the number. It should be prepended and instead it is appended.
Current implementation example:
CRC16 = 8959 (hex - nopad, little endian)
CRC16 = 89590000 (hex - with incorrect padding, little endian)
CRC16 = 13789 (decimal)
If you were to convert that padded hex value to decimal you would get...
2006-12-10 07:18:45 UTC in ReHash - Console-Based Hash Calculator
