From dave at badgers-in-foil.co.uk Mon Jan 12 16:51:27 2004 From: dave at badgers-in-foil.co.uk (David Holroyd) Date: Mon, 12 Jan 2004 16:51:27 +0000 Subject: [cvsspam-devel] Re: porting CVSSpam to Subversion In-Reply-To: <200401121212.i0CCCQbK062546@fama.hq.strikt.se> References: <200401121212.i0CCCQbK062546@fama.hq.strikt.se> Message-ID: <20040112165127.GA3025@vhost.badgers-in-foil.co.uk> On Mon, Jan 12, 2004 at 01:15:10PM +0100, Patrik Sundberg wrote: > Hi, > > I am thinking about porting CVSSpam to Subversion (SVNSpam). I thought I > should ask how to do this in the most convenient way? > > My idea is to more or less just rewrite collect_diffs.rb to use svn to get > diffs etc, then the cvsspam.rb file should not have to be changed at all? That should be possible, given you use the same bizzare, undocumented format of temp file that collect_diffs.rb currently emits ;) Are there any features of Subversion that would need special support in the rest of the system -- I'm thinking about the semantics of version numbers, branches, etc. in SVN vs. CVS. I imagine that subversion will not require an equivalent of record_lastdir.rb? (I hope so!) BTW, I have a simple set of 'smoke test' scripts that synthesize a local CVS repository configured with CVSspam so that the generated emails can be checked visually. I can make these available if you want to adapt them for your development offort (i.e. this is where the example on the project page[1] comes from.) [1] http://www.badgers-in-foil.co.uk/projects/cvsspam/example.html dave From dave at badgers-in-foil.co.uk Thu Jan 15 01:12:13 2004 From: dave at badgers-in-foil.co.uk (David Holroyd) Date: Thu, 15 Jan 2004 01:12:13 +0000 Subject: [cvsspam-devel] Re: porting CVSSpam to Subversion In-Reply-To: <200401122045.i0CKjQbK065931@fama.hq.strikt.se> References: <20040112165127.GA3025@vhost.badgers-in-foil.co.uk> <200401122045.i0CKjQbK065931@fama.hq.strikt.se> Message-ID: <20040115011213.GA16343@vhost.badgers-in-foil.co.uk> --UugvWAfsgieZRqgk Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Mon, Jan 12, 2004 at 09:48:15PM +0100, Patrik Sundberg wrote: > > -----Original Message----- > > From: David Holroyd [mailto:dave badgers-in-foil.co.uk] > > > > On Mon, Jan 12, 2004 at 01:15:10PM +0100, Patrik Sundberg wrote: > > > Hi, > > > > > > I am thinking about porting CVSSpam to Subversion > > > (SVNSpam). > > Are there any features of Subversion that would need special > > support in the rest of the system -- I'm thinking about the > > semantics of version numbers, branches, etc. in SVN vs. CVS. > > I imagine that subversion will not require an equivalent of > > record_lastdir.rb? (I hope so!) > > Branching is handeled completely different. In SVN you do not handle files, > you handle file trees. > One can think of SVN as a series of file trees. Individual files have no > versions - trees have a version. So maybe the way that a version number is given against each file in the top-of-email index is not relevant to Subversion? Sounds like a new svnspam.rb is required the just reuses the diff-highlighting code (factoring this into a module shared with cvsspam.rb). > Could you perhaps describe this temp format for me perhaps? Ok, well... - All lines in the file start with a hash character '#'. (I no longer remeber why this is the case.) After the initial hash, there is a charater that indicates the type of data the rest of the line contains, then a space, then the data itself, terminated by a newline. - The type-identifiying characters that may follow the hash are, '>' - Indicates log comment text 'V' - From,To revision numbers 'M' - Name of a modified file (with repository path) 'A' - Name of an added file (with repository path) 'R' - Name of a removed file (with repository path) 'T' - Specifies a CVS tag name (optional) 'U' - Lines containing 'diff -u' output - Multiple adjacent lines starting with either '#> ' (comment) or '#U ' (diff output) all belong to the same block. - Due to the nature of CVS' script-hooks, we usually see the same comment appear once for each directory commited to, so cvsspam.rb only displays the first of the duplicates. It *is* possible for some directories in a multi-directory commit to be given a different log comment, so cvsspam.rb can output comments part-way though the email. - a line begining '#V ', specifiying the previous/current resisions of a file is mandatory for each commited file - a line begning '#T ', specifying the name of the branch the commit applied to is optional, and my follow the version line - After the Version and optional Tag lines, there must be a line starting either '#M ', '#A ' or '#R ' giving the name of the file that the preceding information applies to - Following the filename line will be lines startuing '#U ' that contain the diff for the named file For example, an added file... #> added some new file #V NONE,1.1 #A somepath/somefile #U diff -u blah-blah-blah #U blah-blah-blah A file added to a branch... #> added this other new file #V NONE,1.1.2.1 #T SOME_TAG_NAME #A somepath/someotherfile #U diff -u blah-blah-blah #U blah-blah-blah A removed file and a modified file in the same commit... #> removed this other file and modified that one #V 1.1.2.1,NONE #T SOME_TAG_NAME #R somepath/someotherfile #U diff -u blah-blah-blah #U blah-blah-blah #V 1.1,1.2 #A somepath/somefile #U diff -u blah-blah-blah #U blah-blah-blah ...I've been rambling a bit, sorry :) > > BTW, I have a simple set of 'smoke test' scripts that > > synthesize a local CVS repository configured with CVSspam so > > that the generated emails can be checked visually. > > this would be helpful. untar the attached archive into your cvsspam directory (the scripts it contains expect to find the CVSspam scripts one directory up). With luck you should be able to enter this directory and run, ./complex.sh to run the complicated test-case, leaving the result in a file called 'complex.html'. To test the email-generating functionality, run ./complex.sh addres@your-domain.com and it should send the output to the given address. Note that this script adds the --debug option when the cvsspam scripts are invoked. As well as logging information to your console, this causes the temp files to be left where they are rather than deleted. Look to the file named like '/tmp/#cvsspam.nnn.nnnn-nnnnnnnn/logfile' for an example of the format that I tried to described above (this will probably be more enlightening). dave --UugvWAfsgieZRqgk Content-Type: application/octet-stream Content-Disposition: attachment; filename="testcases.tar.gz" Content-Transfer-Encoding: base64 H4sIAD7bBUAAA+x7B1RTXbo2FpQiUpQiUkIXQTpEEIJ0aSKI0sEAASIlQIL0DtJF6dIiIE1E EKU3CQIiJWCUJi0gJEhJIPR60W9mvrmz1ox3/fP9M+ve4V0rK0/22efJm/3mPGvv5+yDgMAR NmA4BC5qC0aARd0hzrAHEBFXF3uyPy7ExMXEgNLSZGJiYuJAabG/fv8RQClpIJkYUEZSTFwK KC4lfthfSkpSigwg9gfm8HfDA44AuwMAZLbgB5B/1O9Xx/+XRtStmxo0VKxUh5BG84aqARnZ sdVDHHHyxCGCgB7++MBxS8dQbW1tDYVC2draHhy2dP88146MgNQ7IDtsOGhfdKsgIzvbramq ZOiVuWjR5TJdw8Dn8oHcE46jDtkKOZVQn8YebMc0Qsnii23mFlsJCfTtvAyKpm0UFli6iTpZ ofPa60V0hKh+7nBgaivnAm0Vw8C5WAKy1R+gHnzAjzTH2r4E6GwmSZ802oSkY4Idd3Mr73pw NJ5kaHlufuNZmoGcKRcLZ9qn+/dGRig/2dz66LR8gq24tDcgFRptwtVtuk9LO8UhS8F4ASX0 IuzZbgsz24bAJ63d+9OQcKQ5iU4l7Zs7hkb7at6xV13bdWELHa5Z9c2IsScPeSKJ27St92pO DIZKU4Se78/IcmVaCkQc8MSBL7JUMYTsmoZbJioGBUoi2hWvV7Ruc/JebcMtznBTbdqlvebt 7aLWFzi7KzoD8bYO3ZVVSt5k9zZ5+y55vwmbZ8TP6/3Uyorju9ST1OcpSXI5oE8pK9KgZ4Yr Dz/snOJxWImI3E1kLRHfrZdUuOV9tjRmNlOQI1c3KtCs6JuafEHgqWT4Qn7t6X2tgwo5S1mm bAKP4rgpJSFYL1p9DCDKIRxoHJiLKl3RjzH7Fv9dr5XApTfSh6sgmD2JLy3QFEff8jIOsJdp yufaGm0Wbjp1UKgf9X0dLMvCZhSa3tdevS2wVVDoelzdThIyoEh527tEyzNIOGgFANM6cGwr bnCzorbRkU9a0Qxk24VsibXznArTA4KLvnVojZcMJ0fAjk14hqCVNs2x6M6MS6JxaxD9Ib1v fDF7Ak88+49xRr/mKTOaufPZSqSrxHT8lvdm0UyhQbbNAfuMwCB8voXSXc1nzf4b7SpnmUvS 0sf2taVzF/lpFc8MtNflljy7t3pzObB8D+st3XbW2yrxHPKjvger1nmo6a6rN6/AzJ30WZFt TnYlNsqDLfWIxxF0uHgKevbe3bfrmwohF52YbTZGrA88FFefEpXw8ZV7Ldmnq9o0YQYzeU4R tycCopeP4eOvbAQoHDBIv+L8LI4QxMS5OZa+bZRi9BE3Gw17NSty0qkzl6lAV+Wq1W3R3Nt8 I7FMfXxnuXWji96YTO3SI6bF83M8W72YEsRPfBp5/I65P59P6AI7AjgbzlWsgT7HmxAXi4kF zddwym70qSydtajH1i7lMUPz2vxO1130dGQfcDJFsLTUa6b2zstBPpwUwA/TMPoQ/Vxs5sKs TynQEswQ5ypww0AS/vWQ23v5eBdnugEhvLCtaFwnfpyH34H/CZ1/L/qZwIBIHu5a9blKdrzD pOJA+IVejNnr8xYu6qdpLiOYT51Yi8uNgfMFiiJeMQjJ3qVjJOVkl5lbPZumhz+JrAzLTmfo Pd1w7Rhj6yCDpcDSRrl7+cjN0Adpo3lCRaH7TCcj4cCWylapVefqROT01KJLz/LjBUHYS8/5 HUyXRi+/gdcHJ2vp68mqLpN+9rZS7YFM+RE0Go7UnfYX2CE8dxU5vwvpcD7CyQXwIzXQ4AMf 26s1D9yFd7e6RhU21Q+i8W1kuOl+f+qZupE3sBLzzYksucRhPyoEfoaePfvOtr7P1Gxivp98 3VWV8yJNZBUH+9McfdRbqqtVRSe23fDhfgw+kgV7N9CefcOpy7tbX0k0P1sD6HsjLpmLsg6H ytNeuaI0kdBsqv2mh0RcsFSdWPL2yCQt+77dUVGw0nvGObl1fMxXx1lCdyyGdDLr2HaEV1PW 4pZQ2f3b+/ev9LzAzZsx0wXjObFbcie/Kj4kwfFmK0aO0LsKE7kTLSTXDFZ5mEXNkGX6BqlB qoV06uY9t9x578jz2KbhtP5qsuJh7fYgBkXTEsiuVofMUG+rkzVbm1BsecdmJmY0Kr3Zdrfz a/z6pzbk82FVJxzJyXqYlLAsje7yypXLTE3w4RjxdhOxP0ed3fy+vpCUnZpKLN53+ZKoX731 ICCYxNCXepVz0EYd6lMaZ6Juf1qBFu9qnYDT7exMILGv8puZ41zz292+FBC8517U1d4b1vha IqVutwofa0F7g6QAp/rsFWDf+ITbGbOBvHFcVcAWC6zC4VejOjZzVTtI7WVkdaZLiHK/MZLu VfECnAJavW1ZOq4Jhw1up57k8inB5S4WJg6Upb+5gG6V9PY5aftluUHxtav70891OMcRWdeI V/YKZWuC4wuKc5fjSH5ere1ZQ4LVMvBsRYFlsQwK/It149XdpGet1ipzW37WeYtnurh3cirY CVnTRawKZY5lWudWkQxvNQg+HDd51xqEb0r4GB/jlPSZIMlk6whlo9XeJeKS39rFzj/OKx7Z GsKJeI2rzjqtNTiyJOC+hLe8SWgfVFXvy0h50E4KlrV7g+v5kIhjBJ3BjnCa5cJm/RZ4UhT0 /NoScGDwknXcBlJQ3io0NVvxy3A6I7rjnHF3TDaOyms+xl/YGdZfjPPOWkzH3cYJbbH0d5Tz Xj4hfmk+RZ6QCluuG533vuC0MT6drm/tdMnzVqoAemcWde2wjrZDkicRXobyQ6gg2opit/NZ XtmkqwlPAI2zW6PX8Fxe4zlIP/S70LMcFiK++wS8N7uGREJx4uCHHNpCaC/pwTds7fa5of3v FaF3bMmphMLvgHKq4UMx7Avztnm42tS7C1PI1gdumM6bIsfSFZW26Eila/Gx5f15W3wOg0Z1 vJ1GZ9lZW2Mth5bQVpnQMuLIjJrZImcQtvDY+Brr5yL+g8ebz0QDHn57m6aF1qvDH/OnvCte w5Ztwhw27cVx952il3NIN79l+9BC84RiSR/JaSoPVVbBfTe8/DlBgcv6gJDXJwlWyHp/UnCX ZZBkoi56PBcwJaumqjup7fMWaW780R4op5AdxclaIEXLj1gZDhLp5WhDu8zb+FfaXLvw5u2W k1IggeiwWrYz2qYSKrkX3LbfR3TeNjozUYCZ3M4dCsxvtT9jgenY/H5m9X1Wf2chhQUqxkGK LXTm9SoyGqaKVxL3XdNcbjTQwLRFhjYbf8+f00hqhHVb+ptijKzCzytRPPv84Mv4tVmoSrqL jpTFKj+bBb3UnpFYOh4ugEKHfVpdfNHo2Q1GlXmCkSnEeYUhIFaRD2uUUauntUlgCuDyo0Tt ZHEAlFh61J5sAOQVM9EKlKJTYytiD2nlZSPsQ/eDO6J6ewK046O37AsNfXJt7T6xuswxYCai iH4q6TNp02GFcAx9wQKYOevGKlp78wvUW8Rj38PMa7+YQnTooUH8yWlkNHGcWBqGs0ol7sLp A1RuhOGQMcSLqDJlr860xgTCOAJKLo/ngowMEPwpygg3vBq5dC/YYNSfKnGmVCUQH2oLbpyF fmgjsWSLMqxq8Tc08WDXXAR5nL0oJBlAzGuM2UtS7MU3dTZEdL05m5ou0BQwm7y48j3DJb2a sfiy+hSIl7d9v2v3XJThx9WVJxmHWU0xqGpvTn2N3f6EwCzwNvBIfgt9eqGZGZNYDG8aMAAh wyYYLB8/vTgvqtTNYLmWfKWBkOOdYSeAnR4wc6Vz8HEZDjFMJUoscTXbbusM6W2idu5tK6G0 O5yLZrlT6hAFgwYvtL1seipjm7Wpy7ah1IREg0LoOt04rBrRxtQbVpFawf6pSARL891GLr8p AHZzka+hR5wpqTGL+Ires3L0tHWdkK/QV664BI8zNyYj362bbjI1GahjcXYozP6X/p5Lel6W yXvqKJX4WU5H2rDqnM+Jc5paahhHlEpsMpDeUrDcTRLb+QrRTSE2pigdq5ib94AeRCAwU9AS 6OpabR1RJU+f8KfU1favAg/qxf0ksXzLTWXQfVn7Jd0NPvbAYLuL2MY5bucKdsWwl7rMzz+X +J19erbeDL6PUcxpzCDG6kaTgGJjAvEFMJ6GM4RJVQw5tcuNAuYwYJafTtHV6qePsAIN3vl4 xi/Pe0xP3dN34cajLjp54zktjAxf9ERg58mMG8O7xV1qegs5sPPivRLYtu+Swyihizq0hOsL 3LuqcSIhI8qbYlqRoRK8DYjkMj75xTtAuuyz0F63VVMRpccGg3WAF/eTw6Ns96eCIh71s+Qx xbazVIQ+1xTXYsAIYp8ufLN5JmnO49egb3RFKXP87cEBZcfUacDnodElzrKq6NpnXrhmAcvO WXiitYiRLJUCKDmq0XrFAAfAarybLHyXzkdh+v34Xa7LGE+G8XiwFor2NKWowRw41u3EbQyX /Ea+i3NaK/WoxOepWzeVSyRhckMKVdp09RSwGBZvIOqNqpfXtSIVL7/G7hEhVufJ1LHJwTHV idW1W+mWZ9QME5kCz4hJA5se0rDn2RSjL+ouXLG+j7ndZ06eLQtfLnjocSJn8qFLcVk81pM+ W+fKBYZ1Cuy1atnYfhfjUQbQEt2C/iLZG+lAZvtxhJuLJRSmK0qh193GZaJhYvC9g2Kitger Y/9+lTdZhzmAljxTafjWMYKql1pZ96UdlzDcOFPcNSU0Hahp4eyUdc7n4e3PpdwNWtGucqfp ++9+Np4IJt7W9uqtufOqmK9ABUzt1YWkx8Dj39zbHnFON0HB1SjKIudQ748RuFB6NFiL2vvz pN4C6ky6lUntniTMrXwrnCpqZzm/MYp4G0ncpVkH2b1HsEFLNAUwPFhfCOebdEHfEsPt4BZX SZRJmm6HY5ruJSav+LuCQ6YX8l1TYdoCd66lXFxk1K2+7ZchQ8dR7T+LP8XktLZGFiBDSUEI BEA/BajgNWl3KETz754z0nqP7CLPeOvBv136Yk8n4U05tLLIfeAmJwcjFTxbGqMGKhDf7SKL uXZwcwlec9nP8YJdzr1ts5W600RJUrXgXXlKcpfC+W/xD95VB/u7nqC9xljfD4QHY++TPp/u Frncq2fRgTBpy9m6/c0OiiRm8UUWpjKPdDfyte10XNa9xcsGFiU6Rl9gWoHaZkyj20qWiz5t cWCe0PQilMMnNtNQOpLARz0MJ33n+HbjWje6LK8pu9BgooWzBUCUFefC7nnrebbg4VGQ9CTo shAV4ja58iB3D8j/xpCz3CJlUS/3TZdWbRUP4czC+nvKtjYO2xIH99eq+6Zk/B2uWvsEq1ZY yRGSV0PmVsXblaPM1rjA1XMhK5HZuJ10UsFt1LlHGP/LszqFHzeGyzU5GZoyastY9q0DQQhM mMbDgxNupfbjog0XOX4sdTXVbqq+Ur4X8m9bp///CsR/93/AtrZ/sPlD9j/wf4BSf+P/SMrI yBz5P/+K+GP9n+E/+z/1KdOXzs3uxhyvGPYPkd05CbKXb7E9iXgW+45q9+7J9KDqveLLS89i rlQrfB3z8JFiOWZ1Z5nSLfH9vmUqbOHiVzotV9bJorFmukjxCSn+S+i6oPgoviR7EosVql4F jwzlSMtO47gE8OvuodOaMtG//i4YyeW0+vJzBjVFj2pFCMM94927WuoU3pAQCKX587Qvatad mcjnvMKFz6+RHMUMXpSwLsKYgVZJcs21nwyDhl7pGqS9Pb4Tcf6NUlrpis3rl8U9FK/9DGCM /ZnfPC4f9/56ibsme3n9+Y545zs6juPZkpbpK23vztgYBabbbNlN5viBxZPzV9bUWgIfClLV LDDLc/kFzHQZcQFqtCGl60Va+q8vn7zaYWgcqe19odZvemnBQ2apmvpqQhGw+Hu0aRIUYO1g 0e4k6aTiF9CYfV9SUcu3sTqYm2ZWb23UctH52U1SXLhVI1MJjSG0ahW2OYrnlL1aDo/p9Jwj zDTkNDs2DokOtqdpHbTMu44PIKv3kXLb1AXk0+H7p0QKlIL2Qz5FGgQupTeyfYTLv2fhGbrT LXA5a2tA7jMyr6KLUAZK7SW3a9Cx7WMSYQPfOgCCr7PfHpgg20qcsbv7inEdeKosle08XnRu RKbogG5TYzuxBRb9dCt9/uBrFpi54Gbot6JUlvt+E4gJYofPIOHkd7nSSTQ5f51QWLNEz/J8 4PR+xbCVLP8EZ6LiGIVlUKAnRnMrghmn+PKAntFvv75yM8CzN+kgMmlrRmjF/vPERxheERy9 OzI48faL6Z5IgGXO3vE9rmaXZfIybE41hFvm/uvcwESrSFvl4sAMzoTlF/KeB+JZu4LAspUu fsVzaobFiqNOK7tUfF3lmVZGW+TzM57WEHnnkP3H3i+IqSuJ2gkCzalzGzO4punRHjRpwiOA y3//Fq1zgFpVp1zzmS3Z1VlsocMK+jG1dgSvzZOJ6wX6Wp1j9+jzWqgnohS9Dq6W9Jd7P8BZ DLbEkc+6vR3oDZd+WmN5PSrQurpro+e858ygWsnV88wmTwp6FecWRHdjtyL4e9z24tcBjz4c NPXpG5yTk92SVVBn6qLEs7hPD+VuPPhY5MtbfvdsbnUWE/sr7DTVy+Q35oRC+eHgd1qy2lVv 0NPetl8NsyfmvGuT7b6SWMKYPPpkt4UURD0ZRWh9A/Bxn3rdT6QqfCBZuOHRy35CckMBzTia 1Zx+0qs867Kq1AJlNIvrEOlzKnMhE7A7YzazrKh6yrtlM0VPleLDIxzUOrrULaCNdHyn0DGb OcDSmBoz3QDWdbytiSZJXYKn14NjjK5XhdcrRQZHXQ3GiuBokt9+8B4n+RHTSH5pSUssLmFC X7+sf2GvjcoG8gml9MsKxxV9G6cjSrXTB31yqHZifGeix6ZSMS+ch9NNae/LtMRuGZ/pbka2 Bj1blg/l4z6fVmUYd1qHaiio9xPVCWiCE5oJsfteKGdQfZgujTL1/CVMEO72uzjnEFx+uTqm RqJgDp4tX2ZaxvqiQpaVI0XMnVznDEtPHo7PHHrq1XFH5XQQjhpt9QIFdXNpI3GRqSgyyqP5 LM/eq5MJPmnrW1NphDc+X9oVFOlV+coXdCpMo/nek3A4FdroFVoB7e1gNrk9k5GtZxTNWquO AJY3vrszpWXwXn2QVxUN9DQGa/hmQweCrABAzxfmsnFBuJgsi+MG99q3O8+XL4VdfOTIItLq MGhRK6L5eYCmrd+V3rlspowTzaarWuspsmlp4gRdvsz2mL7JWqoi1E8nL1u+HZd7sNrrvh7H LegfkCmhe793ez0PCL2VTPouvtBclhTqKNDxDalotz5JvSeZy8yeicubrrjUq3+Wtq7lpXbw I09v5cDoPew+6F4e+wMKpZ0dnVWmWO5v8L4M0KKAcmAprlAU3UyxV1nlK2W6rznWJpAzz3Is bvFNfzG6p+ipP8hnk/0x0rdxo9dPpLf5VCO7q8JGtG8pztcedL6uliaLUxUItuS4e9r10dIy vocDCeCewhpKn6vSulVFCkUCqZ3H9BEHzZQX76gmP1v6egYqhd0eMG/WFzCTqX/2/pF/lkhc y56BdtS0A/dbUpsD90h27XUpu5fDLq4iIwWRuWkVWZwF7lJuZ8Zgwh/XTeLmnlc6lWQphoiU Vywy1FE6qnvm2K8u5pxo4fFJYrBwWr2c2l+qq6+AsGHwCUFHi7ft7hpOTIpS40GSuV0QBMHs CVB2a7yWofEJ9YQyzgBbUKbW61tLbaHJ4bldiT/e+ypHIHAi5hUq2uw0u9F741Fmoxh8buEH qsaCLKsHxip6n5TsodpzMnJPHtV92ZzI64O8eErzdTl3Y2+LHBG4x9IU3Mtd96GPBG9/XvlB zLE5mMMlfaff+dHSECDEyn0Vv+XqaXGdGZhbv1q7ePzudGxLsxN7FRTK3Kdyj92CdzV3/DW9 bU1btTn5eJzLg7zQIdaxO+Eb1x+OvyVxWIBYxmbefqZSpFTIXsO/VIPZxXGEuRgqF9J0yKe8 sSBckIufcc7JUO0dzmtV6GLkr13IAfLg2bJweBIN3oAcEW7yXJhB1He/LqiXciyLFce36o0Y T7jVH9bbP8/1ulr5ZRxY9AFHaXqLfnkbB9X1O0kaEboDS37MFsYRx8yq9APleFffWoFymatU Nk8P2Wm0Pg3aGzOOdAN6QNyqr37A95olfWcqq3p/J4rUaTwxYRPIYfQO2SDzJI4/QMpjGWSw wPcoL8q+E1nBXcV/6yJ4XsAj+KHwqYyYUUhxc7n+4ahx3sTp+dwcFp9AI8lvczobyc7jWz7d ZWWJD+kofmR12d57gpxDalsLB5Y7+2V44IJlxBf3feqXvoqr6HrCVP6UTiC4stmwSecgdgXi IxI6P9+/PsDFAcpF6A5iZXQVCgUeiCEFLVC0LQ7f6zZvBK6EdQywl0XX3kF+mLIsTZwL7fUN qZzTSPJ36i7dflsAa/rAXUP2DOWwple0g3kkVfv+QsK97T7tOzcs53fjxeTmSJdQojeg2wE/ 3CIxbDUMzJlC/OpZLooKvIGCycA5k4hWV3aj/ahQraMZgd8FtbdBYakRXd682H51CdYdYoCw JHSEAVE3PeZG2PIsAblpdKKe3XkzsurJ3SBv3uuGwtncjlN5wN4+v/V5T4N3d7Zc/kvdbsOV ht1bYZxVAjYM2JkIbvmhylTiConBMkAYRXh8w2vrNUWzyv551EV+J10vx1flXa0sjszu+Wk8 YUa0vH7rBh+zasMguV4DZDpAsIA4tdmJ1C6TrPycjf3wDwW0ZRw3vGDbNLVhJVNT4WICTCWs 6xQmXHK1EibIfEEcVij38Zy3e5OGf79uKwyRnMPuIKg+lFiee4OnbibNIoxz6DuDqsomdUl+ XsDejQ/+YcDVKsGKs494du4oLnHVzajuVoJ2J+NgKYAUCuQ16/4dsisZUtUM44rjymqtGZGZ c1VaGIEGmmsd8avYDYamVVB6wGNie6WbA1ljAGWNoowF6zhfg2tq27W3ROow0UbkF5+UWSZU K5O9EuEiQ/B6u9TPDhS0NuzpKaO6m5/PUod+/MjfY4mqVzenpkt5GuAxk16g3RpjZnUpQqat dX/7JnVz46x6RQZxeI8R3/6EWPFyJyus8Fp6eFUmBaFs09bnQ1veHCO2mM1mibthwqLxsCNJ g1h7WszC3SckfPkrBQx12ymbeAb5qFw9Vhq7payHGZSrxyBoYNSJ9ZQwCRRmvovRhfbhBsIN aS+AbUHEzYTj9CcVx9JevTEV7dIsmMBEGJm7CWIbIdXnxvdamhziCt50rx4OnCs8V1k3Njji WjsH1rmQTW/zmuMYYQHUOrtuDdzmQDnqE+g6TjcYNukHJhP3xYeJTYoSY7EVKptCJZBkYuts 9kJL89BipnNpczixtv+LzJZC2Ea1cIZ15sXYBHZUDPdD23Cid6odVeOgOyV3ydoCe5xTFLGK Vx55Tf12d3r/+cRNG5szEabxBbgwPUKOzvECq2pKTv7vL/giuzJCmpFefl0Fa18JSjoL21/t kMF0PlMg390Ma6/SzBmWY3QwgwNhBnNzR/nkvsdd5ss4RqniVMCKKacrY65JSE04cShCkAKN yy2A8TfER6Ff1C/FXfyIoCgrb3XcZdmPrlbCctaSfyyj51gcWGR4fyWMuSDyNS1PA4X48eaK Pi55JoHJsXaHt/XEMw8gQcR72y1MTbvyaoXhzOP3RF3Csr74WGw4qtuvM0HvY0LfqXS8l7R/ 9U6Txqu/0FNlcJXdfzODAik14LDNhfIskA0LSq35mEIctl9e0MmTBpLRda7acQTc54DCdNGO CmXQ7wmVHwt2SmTVN30kji9hjjeDPzGA0pes7Q60HFQKFCOJtU1Epa7siuHWFFr+hjC9Gk2f 4+V6Xs+t/V7eimFEwWjHtFAlz2/slyKfCXtf3HJNIipXhaU6ZWKzGp/ORX8iul7xwUyzR1yp In699oyZskwCFdHFodu80odVUPbickTV0588jSGZDtq+3uBLZbO8mQmq4fUjoMmXuHZrrnvt hjhu8VMvQOH0iXyoje8BnQ4TAmm1N2z84gBEB2cpdrQbK6N+J9vEy25Z0IBWbbkIMW5kUWt+ 3T2PDxJo4vVSmkdeP5btJQOW77SVJnfDxWJjaZRQTtZaNf14t9Y77WJpkt6FUN1Nw9cPjXTr X7j2BZw3PExiawkaaZNdmjyw8KRxKOJACU3cNyDKL4ffTzs1eauu7mRZa9lw1qQRo4j8S0fH DiEO+5h4XrPtopDKGXtTR2C3iK7EQ1Jd5dUSuYKuy077mR+nSiUaE3oZ3lspBnzrGZW+PK7Q C0knrsPlLIPXbaJNBAs7v3KgS+xbn0QQa8Tv9JuEuBbMv7y7P9+hhgHXmIoqyS8uL9l3DrZa 7vB5+D0U9F95FyicomqPVO4bhn+R67LI13Q22z//YFktXLjpBrwaVJ0OsjUO75Ub5xZ7Pm9c F/nwvF3jqtqW2kZFmmIXZrQUTY+hfq6zl0wsT/Y0FivBOzKJ0tSYITMoy958gj9fyGDuKn95 IxElSEiYk8UyD7mWgKx6Ru2TAocVRf2hKKGZgyeb29yRbXQ7P9a9/5fMoL/xf5xgLvZOUBcI XMQaYgdz/2Mcjx/+j4yU1N/xfyTEJCWkycSAQBlpcRkxMWnJw/7S0kDgkf/zrwhxEYDOYc0B P4oOgLoAbGAuCIgXgopKTFxCUkpaBnhV9ggdoSP0fxSB5BEwGOCH7AMO9R5wqNRiABuHQ0V0 gjpDEVQQWygC4AzhoqKikvhrpQA7ISDuEFvAJU8owuHHCS72kCsOUHsHp8MXQvBIPo7QEfoP QL+QjyMZOEJH6P8+OpKBI3SE/uPRr2RAUgSg6+GEgLo6QX7r9dNq+vNi4kgmjtAR+g9Av5CJ f3t+R+gIHaF/swpQUUn9leF4OEmwtf0xRaCikv5vzb89sH40dzhCR+g/AR3NHY7QEfpPR79Q gX/3por/RfE3+3/soLa2Tt4/7vrCRcB2CIj7H/Edv3j+S/K3/T8yUuLSkmKSP9rFpYFSR89/ /UvC8LD+cADMDoBwgAAE/nIH/8dWIPDPKbYAwA4CRni4Q6ioxEUAKj/v9P/s7OkA+2HjHXah ogLDrW3sIXb2dtD7jk7OLjBXN3c4wuOBp5e3zz86ZG1jC7H7bWvBn4idYXDEn7P5jVrs/51a luqn5fgnajAC8KPUP+n/lPU/IUW/rU9+p4a42P5O/E8om/VvK5zfia1hCIcf7PA/JO8f9DK/ 0zs5Aaw9fhQbioCCnQAI8OFxyn+ymMC/0MNcID9V+R8PCPjXI3319z+eJ+wnJfwXgwy2/hWn 7F847WAe7r8m/fH7fpmouNhfWCE/L6P/Sa6H6LfBs3f4e7S/X3lwqBcCAnH5B8R/5vpzif5h vhJ/dUlD3RHevw8w4BJIUpLvT1t7AC4wBOAv4gCx/a/2rnW7bdwI/w7P6TtgabWyU4uy7JXd etfZVWO3cU8Sb2V3t+dEWQUiIYsRRbAEaUXNpq/aV+nMALxIsnyJvU6bED9sCAQGwAD45hsA lFZc8FmsenF2lGuGhdnxPAAZ5YfngZ4o3AWLA/P7qjC48innKBtW5qEIRCJuL/564dDw49AT YQJghaj46BEtG6rVPAiEgrHJ0tu6p0nMfVi/50xF3BVFMxjDTLAou7SVsTofZsPFJcMLATDm SYW40JDDBl3JSiRLQ/9dUQDz/6HIjw91gTAvADKK/L/BAsWyUAKKAShw7y20A3tFGy7rNBV4 6AU0DbBgS1c3gLCNf7DX27ASTi+XQFfGFBC1AAzv0Ic50gy4SsqyShovpBbh8pyWdfbsiB29 PKz4383DFfzv3m6AX8v/2i16/7+9vQ0cEPK1dlut6vsfHyTcD/+7i1N3Hf+7m+ir+N8dRf8q /O+PN+B/dxR/Hf+7o/jb8r8biLw9/7te5m35342Efiz/u07sbfjfrQTfL/+7Tc0fy/9uwNDu QP+uYZeX8r9V9O+m/O+G9O/W/O83tyWAH8v/lrQ0uCTcgRPeTP6K8ao44ZVh5ft/97b7d5P3 //by9/9aLfz+p/bXOzsV/3uIUL3/V8Wq2Jcbu8H7f8L7qDcA77K7XsWqWBX7v4hVr/5UsSr2 Zce4gYF+BQNVrIp9wbECBvof9QZg5TRUsSr22ceucRoqFKhiVeyzj33cG4CfvNlVrIpVsU8M Dp+8fVWsilWxT4wCK78N4FNfq/i/CcX9H1dOokC8c9Tovuu4+v53a2+Pfv9tb/fr3b3d9h7e /95p725V938eIqx91Rz4YXPA1QhWk5Jp7Aq6D+xgwhqb8DFeo3Rlilt2csiiWL4VbqLw9uBE KH11z7ImY8+PGc4mk4HxUCYjEZuPluV65cdWnIbuhWL+JJJxwhqT7BJy36SURXnRSN/dRiGO Y8WThcpI+kKF11Uwn31FHYudAI1EMkoDnuhL8HRVkeWPTZ3uSLhjmc51YrH/1uFx9/TABuXz eDb0A0CvQcxDKOrpT2ISJebBMA3DWchB3XhHEgaCkm2j9BpKyqoGJ8kkWMIdSVY3kMj8REyg +EimgUfXeQeifKPXOjs5PNk3AIqXgRWVsHig5Fzqn4//8eKIcutuQirHu6X6BkhWD49hFp2H MhZenT1hCVdj7Hy5lXla3tAGJk8EQ+3GWMyjW7x9UHTYh2fl0iseAYiBXcDRtmMB6faqjKZL jeFSBhyo0qhYjLkRqLRz1mnqQvgDmcwpp5tfzWQT6fnDGUXXmH59xoJ8pWY/xodmhlFF5SGH rKQKGz/h+oIhMhdwZGiy2qAWqsaHMZsTvZxaKAMF9hPZ1zKKHAk/Z40BOzs6Pev/qdt5+fQZ PINFn4+2Sgc4xWQIrcH5viggjTxcCo14QcZSP7JpOIzlpCQJu6MfzXcmT1sSlHUTVWJWp5G1 yUK8XMzEO18leIPaD6mmBOSObdYDaY+eFNrbvlx925fpT0UwoY32Lstp9Nh5eXL27Khr1HBZ xlxfK7MWc6MAACifyBSqNrNWz7PLNJY9KqSUACNTZyMUzKbhJb1O/SBgI36hEa18pTy/Nb88 fHg7m0hXL6S0t2BHGYyFaDzphcWoChlYK6qF/xNfKRqopK5WVCzDxepgRAyKIYJRjVgf7g6V KrMFd0f9wSwRli+Vk39i739h9B/+BRLg6wNrPGGhTyV1eMqDQFGt5/6FCE0+GbqCOCiK0iLW txxnu93ewIkGlWyyiOv+QFmSRrk4jA9M1fg8nYgwcdgZCFYJoNOETVBp0AsZiRCVK1HR3EMR Em0POz4RcSxjEkbDhCuJ+0p4jp3jIzS36HaEsqzjE4ci64w/nXinSQwiNxl/IT2hPxz07Lhn sw3sPA+PT25RAhSIJZYVmOmvm4ZafSoSrl6ruJJ46GG/sXOoEoQWsIUuUIhvdO78c12RLLDG ocdjMClhlKK9hjWfJhjNVOHKMARbChUYeIpFksaoSmifHKCdddjxkKQV3dJm3rxzwFnvTe9N o17fRAH40lsoplAjVu4S4emmgxlOVioForlu3XyT9bB6YsjTAF8M8fRcwUwojya8bhCKevMm xgoHaaKbVmgZ+NYMe6ZEgn3i4Sx7Gw5lKpxpZ3wAwra3nTYujoifC7azvesU8/d4CL3QYwN1 0Rze1L0gvQFmkMBsTGgw3JEfeHP6tPRQUinSU+RHwqEUvVizhmF6PiK4AoSRCZgJlAUXsZFG sI/tAuNprW5sVmFpxKCq8jCZAvmKgB75oa5iKkF3WDOsPDM2Qu3r1WvsAWJ5mGzqCWXSjQb0 MOoMJM+IWOxf3m8zpkv9LVq5maOB1jFYKOXDwBntzffEiIfVpJtH44TF6qq8HPSsofVk0uRV q0L3B6KxTM9HeeMd9lKaCXjB/YCmFRpVkBIBBYP5O1FOzjdmBcYAO8LZSMBq4ogBPr5LlE3C H1JYYZACrUW7TXyK5jCqGMkl2EIlhmkAVQYzHIIXp43Dk9PmT37oyaleYyK88GMZIm7CCjvB seIZdvq0GEqCN8GMMJeHhtvGQq8hEhTKsNyEEuso07jll59ZKamcc/FnsliesMD3coQ29qkw i0armd0uVVQSZsz4Mh+RE9Enm46sDkZr1tdumHHYNBknH23OQ9mktYWTRcvCtTUT6Nfc3lm4 If3XeUMhPMU8CRVaQEe4EtqRoJ6wxIc/SsrQCqQcKyZBc1NEY0NIym8EM8VniqFQ68WMveic YvTl6rbOuR95Nwd+nIxu6WLczDEofIDLPARnfnqY5CKxcEsKkde6CwWnGgEQDfD1UDory8jT Cnos5+jxE3O+ttg+Siqx8Js5JIv9mJdxRw5/PVu+rhVok3EyldAto9g40os6KFVTuOKQS/vf NlnSTYjazKa3NhnG56XMZarnuep2Aas4Q7FBRdYmJa0SZJ4ul8+lX1q+Pv+43ALsF70BxoEA sdEkCWD1JX4yI7E6+js+ib5BPS/JXXiuBftD9orZtZNTm311wGyD7v2XZzZ7zYj4aWu2hnBy AWCvwQPX8QUPfLR2NLX17kcaejA5pmUTUcyqhdYnE2h9INB4UPMx4dvBk6zpC40vPa3j46G/ wocqmDaYUKLNyAOIRnfimM9KfgTYqURoZoA+9FBTBsCzCHAQcH59zlKTX0FrYYNsu+ayOdmc aJIBBKdhegWKgvpQbs52gem8Ihfiz9BWAPsY1ipG2esbGfsShzTY+45jzwFTAjnV1AsZVk6s mBtIlfuNao4SomHIGj/LBzVFB6ngAJhEriNuMSpgT74L7McVyUxTMexLZgG4ZmQ53cSy5+A4 EdcDZ8lko7kAmgWcQp7lU5OgdmwB8mlSSqyMT5UUfAiYBYpFL8jJFIBb43mvNI0yndfaiD0H m1g4aBq+9Nhh3T6+qC10R7UpBp83RR4zjR3SnmOw11qclItpS2j2QP78Q3vzev+g8OddIBhN T1w0wxQ6di9e72fnw9qNnv2QHiwp8lfzYDvBFEleFIuh0E1AfDLeIR/Q7qRWVigbegRVMgvE Z+8D58P8RXvAJAub/Ak84EudRfquhOt9RZ1tybuDf7Wfnh11j6zlA6SF86flU66C+pVcOjya y27ZxyKSyk9k7CMVSWi8sUvdo87hi6Oyv2NSskPAGnAuUEhfubEfJehaUi3IeF1kNjCEkLZe PhtEP87AJhVS2gyRRzKI5Rj+IabQwZqn7fPG0sFgRqsBdeAfatK0zyQYra1l7jB9e48+u85e Q1bo0mKxxt9Yw9PKbeaKmJVPicjOw6oraZCONQGUNpkxb7GxVtARyGF6KCYwYxA/NUKzY8JF WHXozABCxcGsgUO9SV+zAuYTAJnWpMf/A8WA6+H3LORTFtb4ZCI8c2qEtCGrjLNTXck+2EcO /BcqWz8JBX39DCz1MBG4hAsrKkKc5A5o1np1llMfxIVBwMOxuSphKqIuylC8tqxnZy+e40mG ymBiXh0kRSiXR9DMwB/rsvsMWDNW8m1z8MQ6lToXegI430w2KDuJYNUT1CZ61YtzPwwNrpkR eAdd/F2QfGNZHfb37vN9BiQ+ifabzel06gy4dw4iGn7YGEo/cFzppOOm1dHLAfKuzGQd0VDB FIqhJ/u05QA9/h7/T7Hpjh+Sr2FZgMSD9PxfMCZo2yM6J/YR6XEleECokRGiQ/IO87EWQRDE 1lpbLcf6EyThhQYygZpMms19GLK/Hnc7hvsde7jHI8eknk32126n0Wp/3XasrvhnivPwDOjS GKGC1AcQxoMxDYoAQEKF1YEnj0Wi6psmD31krZ1dB53k1cfwsPBzKkWXZIr7H0M+hsUORg21 5cSD+7tjcM33/7V2tnbo/sdWq91q7+Hvv3+926p+//1BwtpXzVTFdAckRqLTmCK0dlxXRHqh EiposAPTqBIvM7xcszDOcufbyxmjxkwen4MsAyYA3TD/EH0LSg31kbEQ6K5hdlgnJwSg2XHZ 3FYiof5UA1GJhpDfb8iEC7ab6DHZH2Qlc80hmRashfM+lTpgne5ffny19drx0qhIdwDWv1pv 9hw1qjU3mW1vLD37+dXPvebrx72meW6Bte6j2TIiW68tOqhjdn3tvXn2oZ65vLxQh83SEL8w jKGfjt/GuL+fP/tu3ZTcwJ6rsR8xGghtB5RVo+HQh5tkoDzJfsHIL2A2B2Ckx+iC0pODf7Pm z7WmBevbsrAqhzwlu2hcc+193skPDu6HANW0p/YGSYVcKPTKGhmSMAecG7WOSRvonkF1VCUW FHFMT+c+MPvxY3aifSIgXa6gLZ/6UmPqmW1NRujrox4g6+PHdnXX7y6hwP+M7kV8cs93AK/D /+1d+v6v7d3dHfriV8D/ne3q+18fJKyRo55G7OmPpzj0GXOfc0vcEThA7PdTVoNc3ZOTs2b2 P/M5hvKKTIE8pxzaV+k8f85qp0+7xz+cnQIpd2Xs9XFDCDAIWAfSF7ylc1VNl8hxZRAAZgKQ DYcKxLBGwxNI0RoN2s7q1f5+etRFykeMD5LBdNU6h4fdo9NT9tv36seLDyurnm9/r3bhiyl4 F0BRD3q2oaihnKOSPdvq1TIqCRnBLORZs2RnIvV/GZ83gb5P+/DEcc/973zv4LeKRLz148Xi mOTwJMC7JjwEijtpggFNY9H8Edp1jAzTeQtD+d1YzDIxmh8uCELCzEXiJGnDlUkySJXjiWac bDfPKHvz0Fd4tEjwW2pTxhH7iNAksHZ69PLwRef4ec9G13J57C4UwQqY+SFYsnvQzKdeNp9N KPDfXPr9Feq4Dv+3tuj3X/b2dnbaYAPw/vfWdqvC/4cIiP4NgedvQ0PxNVnW987M9tD6Bntv PcIrrS5PgdOarRU6I/BVWE/YP1NfJGbnYdN6pEas4TLb5Ks9tuf8zg/g4GvkPai1LIuOCBv/ YnaGx3NHg1lOG/3T7w284gldhjkHdu2Hnw6X3FdWr23V4Q88q9uWCJSYK0Nej0K3JytjW0Of aLa2h1xvCQUSXApW2jsCu4GgaK69k4E8oAYkYhJZuOOnP+LXqVrGPB28AeNGDgc+emNZc1tr Ov88/QLNT1gjHmYm2Nz01h9KllmnF82zDOQeLG16WeIdbWeYDPn1+LD6vawvORT4r7d/f406 rsH/rfZOO/v9h1ZrD3yB1vbOXrvC/4cI3VTvwhab9pt4zOGUXgdjM5nGDfK4vzebqAB8uLuZ Q+USStKBkn55QG9l6NMcs6PMWZhOBrhPPrTqfojf/UO3ferli2s+7qpnXkm2TW5qNHtKc7Bs 6U2qkgTaeNYNxj7QnlGWrvvqWBbdRFAivtBlxDsXj6fMpQajEWo7vQkDlPfCx2NM3IMwlyPk kE14SNBLbTW/l6GcClerUIUqVKEKVahCFapQhSpUoQpVqML/Qvgv2LwF9gDIAAA= --UugvWAfsgieZRqgk-- From richard.bos at xs4all.nl Sat Jan 17 08:21:45 2004 From: richard.bos at xs4all.nl (Richard Bos) Date: Sat, 17 Jan 2004 09:21:45 +0100 Subject: [cvsspam-devel] email addresses in a file Message-ID: <200401170921.45629.radoeka@xs4all.nl> hello, is it possible to store email addresses in a seperate file? If there is no emaillist available and many email should receive the log update the command line with --to becomes very hard and hard to maintain. It would be nice if a file with email addresses could be selected with e.g. --tofile. The file should simple store the addresses 1 at a line: address1 .... addressN Is this possible, would it be difficult to implement? Another question: is it possible to execute a 2nd script during the commit of a cvs file, depending on the contents in the log file? E.g. if the first line would contain "DOSOMETHING" a script dosomething would be executed. Would this be possible at all? -- Thanks in advance, Richard Bos Without a home the journey is endless From Aaron.Korver at Fiserv.com Mon Jan 19 16:10:17 2004 From: Aaron.Korver at Fiserv.com (Korver, Aaron) Date: Mon, 19 Jan 2004 10:10:17 -0600 Subject: [cvsspam-devel] RE: cvsspam-devel digest, Vol 1 #31 - 1 msg Message-ID: <0205C50D41B7D611AEA50002A537CEC2016597FB@DES10MS01> This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C3DEA6.BAF03E30 Content-Type: text/plain; charset="iso-8859-1" is it possible to store email addresses in a seperate file? If there is no emaillist available and many email should receive the log update the command line with --to becomes very hard and hard to maintain. It would be nice if a file with email addresses could be selected with e.g. --tofile. The file should simple store the addresses 1 at a line: address1 .... addressN Is this possible, would it be difficult to implement? What we have done is to use the alias feature for sendmail. Where you can specifiy one e-mail id on the server, and have it resolve to a file. Example: Our e-mails are sent to all developers, so in the /etc/aliases file we have an entry like this. "Dev: :include:/usr/local/etc/DevList.txt" And then in that file we keep all the e-mails for the developers. One address per line. After you edit the /etc/aliases file you need to run the command newaliases. Then for CVSSpam we just have it send to the address Dev and sendmail does the rest. Another question: is it possible to execute a 2nd script during the commit of a cvs file, depending on the contents in the log file? E.g. if the first line would contain "DOSOMETHING" a script dosomething would be executed. Would this be possible at all? -- Thanks in advance, Richard Bos Without a home the journey is endless ------_=_NextPart_001_01C3DEA6.BAF03E30 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: cvsspam-devel digest, Vol 1 #31 - 1 msg

is it possible to store email addresses in a seperate = file?  If there is no
emaillist available and many email should receive = the log update the command
line with --to <addresses> becomes very hard = and hard to maintain.  It would
be nice if a file with email addresses could be = selected with e.g. --tofile.
The file should simple store the addresses 1 at a = line:
address1
....
addressN
Is this possible, would it be difficult to = implement?

<start reply>
What we have done is to use the alias feature for = sendmail.  Where you can specifiy one e-mail id on the server, and = have it resolve to a file.

Example: Our e-mails are sent to all developers, so = in the /etc/aliases file we have an entry like this.
"Dev:      = :include:/usr/local/etc/DevList.txt"

And then in that file we keep all the e-mails for the = developers.  One address per line.

After you edit the /etc/aliases file you need to run = the command newaliases.  Then for CVSSpam we just have it send to = the address Dev and sendmail does the rest.

<end reply>


Another question: is it possible to execute a 2nd = script during the commit of
a cvs file, depending on the contents in the log = file?  E.g. if the first
line would contain "DOSOMETHING" a script = dosomething would be executed. 
Would this be possible at all?

--
Thanks in advance,

Richard Bos
Without a home the journey is endless


------_=_NextPart_001_01C3DEA6.BAF03E30-- From richard.bos at xs4all.nl Mon Jan 19 19:50:36 2004 From: richard.bos at xs4all.nl (Richard Bos) Date: Mon, 19 Jan 2004 20:50:36 +0100 Subject: [cvsspam-devel] RE: cvsspam-devel digest, Vol 1 #31 - 1 msg In-Reply-To: <0205C50D41B7D611AEA50002A537CEC2016597FB@DES10MS01> References: <0205C50D41B7D611AEA50002A537CEC2016597FB@DES10MS01> Message-ID: <200401192050.36609.radoeka@xs4all.nl> Op maandag 19 januari 2004 17:10, schreef Korver, Aaron: > is it possible to store email addresses in a seperate file? =A0If there i= s no > emaillist available and many email should receive the log update the > command > > line with --to becomes very hard and hard to maintain. =A0It > would > > be nice if a file with email addresses could be selected with e.g. > --tofile. > > The file should simple store the addresses 1 at a line: > address1 > .... > addressN > Is this possible, would it be difficult to implement? > > > What we have done is to use the alias feature for sendmail. =A0Where you = can > specifiy one e-mail id on the server, and have it resolve to a file. > > Example: Our e-mails are sent to all developers, so in the /etc/aliases > file we have an entry like this. > "Dev: =A0 =A0 =A0:include:/usr/local/etc/DevList.txt" > > And then in that file we keep all the e-mails for the developers. =A0One > address per line. > > After you edit the /etc/aliases file you need to run the command > newaliases. Then for CVSSpam we just have it send to the address Dev and > sendmail does the rest. > Aaron, thank you for your suggestion, but I don't have access to the sendmail=20 configuration files and I can't use it therefor. I think it is also nice t= o=20 have the email addresses in a maintained in cvs so it can be maintained by= =20 several people. =2D-=20 Richard Bos Without a home the journey is endless From richard.bos at xs4all.nl Mon Jan 19 20:08:41 2004 From: richard.bos at xs4all.nl (Richard Bos) Date: Mon, 19 Jan 2004 21:08:41 +0100 Subject: [cvsspam-devel] Questions about cvsspam.conf commitinfo Message-ID: <200401192108.41150.radoeka@xs4all.nl> Is it necesary that the cvsspam.conf is set executable? On my system it is set +x at least, but as it is a configfile I would expect that 644 would be sufficient. On the other hand the snippit below from cvsspam.conf # list to propogate the messages. #addRecipient "global-code-review@somewhere.invalid" looks to refer a ruby class. I hope someone can shine a light on this. The following is about the commitinfo file; My commitinfo file looks very boring: ^qss /home/cvs/bin/record_lastdir.rb ^tvms /home/cvs/bin/record_lastdir.rb ^tools/tama /home/cvs/bin/record_lastdir.rb ^tools/tscont /home/cvs/bin/record_lastdir.rb ^tools/tsverif /home/cvs/bin/record_lastdir.rb ^web /home/cvs/bin/record_lastdir.rb DEFAULT /home/cvs/bin/record_lastdir.rb Wouldn't it be sufficient to have the DEFAULT line only? This is what happened to me last week, when I added a new entry to loginfo, but I forgot to update commitinfo => cvsspam kept in working correctly! Looking at it again I still think that the default line should be sufficient and that an additional line is only needed when another script is required for record_lastdir.rb, isn't it? I ask this as the documentation that comes with cvsspam stated the following: "The expression you use to select the project (the first thing on the line) must be the same in commitinfo and loginfo." -- Richard Bos Without a home the journey is endless From richard.bos at xs4all.nl Mon Jan 19 20:15:19 2004 From: richard.bos at xs4all.nl (Richard Bos) Date: Mon, 19 Jan 2004 21:15:19 +0100 Subject: [cvsspam-devel] How can one test cvsspam? Message-ID: <200401192115.19783.radoeka@xs4all.nl> As asked in the subject; How can one test cvsspam? If I run cvsspam from cml, I get: cvsspam-0.2.8> ruby -e cvsspam.rb -e:1: undefined local variable or method `cvsspam' for main:Object (NameError) Which is expectable of course as cvsspam.rb should be called from collect_diffs.rb? Is it possible to test cvsspam from the command line, if yes how does one do it? -- Richard Bos Without a home the journey is endless From dave at badgers-in-foil.co.uk Tue Jan 20 10:39:27 2004 From: dave at badgers-in-foil.co.uk (David Holroyd) Date: Tue, 20 Jan 2004 10:39:27 +0000 Subject: [cvsspam-devel] RE: cvsspam-devel digest, Vol 1 #31 - 1 msg In-Reply-To: <200401192050.36609.radoeka@xs4all.nl> References: <0205C50D41B7D611AEA50002A537CEC2016597FB@DES10MS01> <200401192050.36609.radoeka@xs4all.nl> Message-ID: <20040120103927.GA24915@vhost.badgers-in-foil.co.uk> On Mon, Jan 19, 2004 at 08:50:36PM +0100, Richard Bos wrote: > Op maandag 19 januari 2004 17:10, schreef Korver, Aaron: > > > is it possible to store email addresses in a seperate file? ?If there is > > > no emaillist available and many email should receive the log update the > > > command line with --to becomes very hard and hard to > > > maintain. ?It would be nice if a file with email addresses could be > > > selected with e.g. --tofile. > > > > What we have done is to use the alias feature for sendmail. ?Where you can > > specifiy one e-mail id on the server, and have it resolve to a file. > thank you for your suggestion, but I don't have access to the sendmail > configuration files and I can't use it therefor. I think it is also nice to > have the email addresses in a maintained in cvs so it can be maintained by > several people. Hi Richard, It wouldn't be technically difficult to come up with some code to do this, however I'm against implementing this within CVSspam itself on architectural grounds. You see, there's lots of ways of doing what you want using an external system, and software entirely focused on managing a mailing list is always going to be superior to something I could hack up. If there's no host that you are able to control the mail config on, per Aaron's suggestion, maybe you could use one one the many free mailing list services out there? See, for example, http://dmoz.org/Computers/Internet/E-mail/Mailing_Lists/Hosted_Services/ dave From dave at badgers-in-foil.co.uk Tue Jan 20 11:12:28 2004 From: dave at badgers-in-foil.co.uk (David Holroyd) Date: Tue, 20 Jan 2004 11:12:28 +0000 Subject: [cvsspam-devel] Questions about cvsspam.conf commitinfo In-Reply-To: <200401192108.41150.radoeka@xs4all.nl> References: <200401192108.41150.radoeka@xs4all.nl> Message-ID: <20040120111228.GB24915@vhost.badgers-in-foil.co.uk> On Mon, Jan 19, 2004 at 09:08:41PM +0100, Richard Bos wrote: > Is it necesary that the cvsspam.conf is set executable? On my system it is > set +x at least, but as it is a configfile I would expect that 644 would be > sufficient. On the other hand the snippit below from cvsspam.conf > > # list to propogate the messages. > #addRecipient "global-code-review@somewhere.invalid" > > looks to refer a ruby class. No, it's shouldn't be necessary. I just chmod'ed my config file to... [dave@cvs dave]$ ls -l /cvs/CVSROOT/cvsspam.conf -r--r--r-- 1 dave staff 4250 Jan 14 13:23 cvs/CVSROOT/cvsspam.conf ...and everything still appears to work. As you suspect, the config file *is* actually ruby code which is loaded by the scripts. This simple hack means that I don't have to implement a configuration file parser. > The following is about the commitinfo file; > > My commitinfo file looks very boring: > > ^qss /home/cvs/bin/record_lastdir.rb > ^tvms /home/cvs/bin/record_lastdir.rb > ^tools/tama /home/cvs/bin/record_lastdir.rb > ^tools/tscont /home/cvs/bin/record_lastdir.rb > ^tools/tsverif /home/cvs/bin/record_lastdir.rb > ^web /home/cvs/bin/record_lastdir.rb > > DEFAULT /home/cvs/bin/record_lastdir.rb > > Wouldn't it be sufficient to have the DEFAULT line only? This is what > happened to me last week, when I added a new entry to loginfo, but I forgot > to update commitinfo => cvsspam kept in working correctly! > > Looking at it again I still think that the default line should be sufficient > and that an additional line is only needed when another script is required > for record_lastdir.rb, isn't it? I ask this as the documentation that comes > with cvsspam stated the following: > "The expression you use to select the project (the first thing on the line) > must be the same in commitinfo and loginfo." If you leave DEFAULT in commitinfo but keep module specific matches in loginfo, you should get email as expected. You'll also get temporary files hanging around after you commit to projects that don't have a match in loginfo (the files can only be deleted from the loginfo-hook). If there's a process that automatically cleans $TMP on the CVS server, this is not a big problem. Otherwise, you will slowly lose disk space. dave From dave at badgers-in-foil.co.uk Tue Jan 20 11:27:04 2004 From: dave at badgers-in-foil.co.uk (David Holroyd) Date: Tue, 20 Jan 2004 11:27:04 +0000 Subject: [cvsspam-devel] How can one test cvsspam? In-Reply-To: <200401192115.19783.radoeka@xs4all.nl> References: <200401192115.19783.radoeka@xs4all.nl> Message-ID: <20040120112704.GC24915@vhost.badgers-in-foil.co.uk> On Mon, Jan 19, 2004 at 09:15:19PM +0100, Richard Bos wrote: > As asked in the subject; How can one test cvsspam? > > If I run cvsspam from cml, I get: > > cvsspam-0.2.8> ruby -e cvsspam.rb > -e:1: undefined local variable or method `cvsspam' for main:Object (NameError) > Which is expectable of course as cvsspam.rb should be called from > collect_diffs.rb? Is it possible to test cvsspam from the command line, if > yes how does one do it? The -e argument to ruby is used to specify a fragment of ruby code on the command-line; there's no variable 'cvsspam' on which to call the method 'rb', so you see the error above. Just remove the '-e' and it will probably to what you expect. cvsspam.rb is only intended to by executed from collect_diffs.rb. As such, it requires the name of the datafile created by collect_diffs.rb as it's first argument, followed by the arguments that where given to collect_diffs.rb (i.e. --to, etc.). If you want to test changes to cvsspam, try the scripts attached to the mail I sent to Patrik Sundberg a few days ago. I can send those to you again if you've not got a copy. dave From richard.bos at xs4all.nl Tue Jan 20 20:47:56 2004 From: richard.bos at xs4all.nl (Richard Bos) Date: Tue, 20 Jan 2004 21:47:56 +0100 Subject: [cvsspam-devel] How can one test cvsspam? In-Reply-To: <20040120112704.GC24915@vhost.badgers-in-foil.co.uk> References: <200401192115.19783.radoeka@xs4all.nl> <20040120112704.GC24915@vhost.badgers-in-foil.co.uk> Message-ID: <200401202147.56514.radoeka@xs4all.nl> Op dinsdag 20 januari 2004 12:27, schreef David Holroyd: > > cvsspam-0.2.8> ruby -e cvsspam.rb > > -e:1: undefined local variable or method `cvsspam' for main:Object > > (NameError) Which is expectable of course as cvsspam.rb should be called > > from collect_diffs.rb? =A0Is it possible to test cvsspam from the comma= nd > > line, if yes how does one do it? > > The -e argument to ruby is used to specify a fragment of ruby code on > the command-line; there's no variable 'cvsspam' on which to call the > method 'rb', so you see the error above. =A0Just remove the '-e' and it > will probably to what you expect. > > cvsspam.rb is only intended to by executed from collect_diffs.rb. =A0As > such, it requires the name of the datafile created by collect_diffs.rb > as it's first argument, followed by the arguments that where given to > collect_diffs.rb (i.e. --to, etc.). > > If you want to test changes to cvsspam, try the scripts attached to the > mail I sent to Patrik Sundberg a few days ago. =A0I can send those to you > again if you've not got a copy. Hi Dave, thanks for the explanation. I the mean time I have setup a test CVS=20 repository, where I can do whatever I want in CVSROOT :)) This works very comfortable and I can test cvsspam this quite well. I have the copy of the email that you send to Patrick, so I could always=20 change to the complex.sh. =2D-=20 Richard Bos Without a home the journey is endless From richard.bos at xs4all.nl Tue Jan 20 21:10:25 2004 From: richard.bos at xs4all.nl (Richard Bos) Date: Tue, 20 Jan 2004 22:10:25 +0100 Subject: [cvsspam-devel] RE: cvsspam-devel digest, Vol 1 #31 - 1 msg In-Reply-To: <20040120103927.GA24915@vhost.badgers-in-foil.co.uk> References: <0205C50D41B7D611AEA50002A537CEC2016597FB@DES10MS01> <200401192050.36609.radoeka@xs4all.nl> <20040120103927.GA24915@vhost.badgers-in-foil.co.uk> Message-ID: <200401202210.25239.radoeka@xs4all.nl> Op dinsdag 20 januari 2004 11:39, schreef David Holroyd: > On Mon, Jan 19, 2004 at 08:50:36PM +0100, Richard Bos wrote: > > Op maandag 19 januari 2004 17:10, schreef Korver, Aaron: > > > > is it possible to store email addresses in a seperate file? ?If there > > > > is no emaillist available and many email should receive the log > > > > update the command line with --to becomes very hard and > > > > hard to maintain. ?It would be nice if a file with email addresses > > > > could be selected with e.g. --tofile. > > Hi Richard, > > It wouldn't be technically difficult to come up with some code to do > this, however I'm against implementing this within CVSspam itself on > architectural grounds. You see, there's lots of ways of doing what you > want using an external system, and software entirely focused on managing > a mailing list is always going to be superior to something I could hack > up. > > > If there's no host that you are able to control the mail config on, per > Aaron's suggestion, maybe you could use one one the many free mailing > list services out there? See, for example, > > http://dmoz.org/Computers/Internet/E-mail/Mailing_Lists/Hosted_Services/ Hi Dave, the question arises (arose?) as I administrate a couple of projects (about 5 I think at the moment) and all of these have only a few cvsspam lurkers ;) Because of the low numbers I find the usage of an emaillist server overdone (though I can use one). So I'm bound to the --to argument ;) The subscription administration should not only be done by me, but by others as well and for this reason I think it would be good to administrate the addesses in a seperate file (to protect the rather sensitive loginfo file). I just test the following command sequence in loginfo: DEFAULT $CVSROOT/CVSROOT/collect_diffs.rb --from $USER@radoeka.nl `$CVSROOT/CVSROOT/tolist default` %{sVv} TEST/CVSROOT> cat tolist sed 's,^,--to ,' $CVSROOT/CVSROOT/subs/$1 | tr "\n" " " The file default contains the emailaddresses and this file can be safely maintained by others (via cvs ofcourse). The above seem to work and it is exactly what I want. However, in contradiction as what you stated I still think that it would be nice to have an argument --tolist available doing the above ... ;) But now with the algorithm above there is not much need for you to add to cvsspam... BTW. I tried to add the --tolist argument to cvsspam and I wundered how I should read in the email addresses from the file to store them in the recipients array. Parsing of the arguments went fine. During the trial above I discovered to you use the variable '$passthoughArgs = Array.new' in collrect_diffs. Isn't that a typo, shouldn't it be $passthroughArgs (with an 'r')? -- Regards, Richard Bos Without a home the journey is endless From richard.bos at xs4all.nl Tue Jan 20 21:18:58 2004 From: richard.bos at xs4all.nl (Richard Bos) Date: Tue, 20 Jan 2004 22:18:58 +0100 Subject: [cvsspam-devel] Questions about cvsspam.conf commitinfo In-Reply-To: <20040120111228.GB24915@vhost.badgers-in-foil.co.uk> References: <200401192108.41150.radoeka@xs4all.nl> <20040120111228.GB24915@vhost.badgers-in-foil.co.uk> Message-ID: <200401202218.58883.radoeka@xs4all.nl> Op dinsdag 20 januari 2004 12:12, schreef David Holroyd: > > Looking at it again I still think that the default line should be > > sufficient and that an additional line is only needed when another scri= pt > > is required for record_lastdir.rb, isn't it? =A0I ask this as the > > documentation that comes with cvsspam stated the following: > > "The expression you use to select the project (the first thing on the > > line) must be the same in commitinfo and loginfo." > > If you leave DEFAULT in commitinfo but keep module specific matches in > loginfo, you should get email as expected. =A0You'll also get temporary > files hanging around after you commit to projects that don't have a match > in loginfo (the files can only be deleted from the loginfo-hook). =46orgive me to ask: why can't the temporary files (dir) be removed from th= e=20 loginfo-hook if the loginfo does not have the same regular expression? =20 Do record_lastdir.rb and cvsspam/collect_diff don't share the same tmp dir?= =20 Is the directory not communicated between the 2? =2D-=20 Richard Bos Without a home the journey is endless From richard.bos at xs4all.nl Tue Jan 20 21:27:35 2004 From: richard.bos at xs4all.nl (Richard Bos) Date: Tue, 20 Jan 2004 22:27:35 +0100 Subject: [cvsspam-devel] RE: cvsspam-devel digest, Vol 1 #31 - 1 msg In-Reply-To: <200401202210.25239.radoeka@xs4all.nl> References: <0205C50D41B7D611AEA50002A537CEC2016597FB@DES10MS01> <20040120103927.GA24915@vhost.badgers-in-foil.co.uk> <200401202210.25239.radoeka@xs4all.nl> Message-ID: <200401202227.35479.radoeka@xs4all.nl> Op dinsdag 20 januari 2004 22:10, schreef Richard Bos: > During the trial above I discovered to you use the variable > '$passthoughArgs =3D Array.new' in collrect_diffs. =A0Isn't that a typo, > shouldn't it be > $passthroughArgs =A0(with an 'r')? During the same trial I found that having the string 'mailto:.....' in the= =20 logmessage is converted to 'mailto:mailto:.....'. Nothing to worry about a= t=20 all, I thought to just mention it, that's all. I came across this because of my other question: is it possible to act on special strings in the logfile? E.g. if a line in= =20 the logmsg starts with CCMAIL: "name ", the cc will be sen= t=20 to: "name ". The above does not seem to complicated (if one knows ruby ;), but I think t= hat=20 it is still a lot of work as Cc's or not supported, yet. Do you have tips= =20 hints how such can be added to cvsspam?? =2D-=20 TIA, Richard From Aaron.Korver at Fiserv.com Wed Jan 21 00:44:12 2004 From: Aaron.Korver at Fiserv.com (Korver, Aaron) Date: Tue, 20 Jan 2004 18:44:12 -0600 Subject: [cvsspam-devel] Odds and Ends Message-ID: <0205C50D41B7D611AEA50002A537CEC201659810@DES10MS01> This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C3DFB7.B05278F0 Content-Type: text/plain; charset="iso-8859-1" I'm with agreement with David on the fact that CVSSPAM does one thing and does it well, that is it sends pretty formatted HTML e-mails upon commits. There are other pieces of software out there to handle list management and they do that just fine as well. As far as other alternatives you may want to look at the notify file in CVSROOT. This file looks at the users file (that is also in CVSROOT) and you might find a way to hook up CVSSpam to this notify file. The notify takes a param %s and goes through the users file replacing the name of the user with the user's e-mail address. How you can hook these two together I don't know off the top of my head. Finally, one might be able to use the log.pl script that comes with cvs /contrib/log.pl There are some instructions for use in the comments of the file. With the DEFAULT you can just use this if you are sure that everything needs to go to one list or person. If you need to seperate the mails out then of course DEFAULT won't work to well. The suggestion for the CC: might be interesting but I don't think it should be parsed from the log message. The log message for a CVS commit should be purely related to what is being checked in. If it fixes a bug it should say so. If there is a TODO it should say so. These are in my mind legitamite things to parse for and act upon. But CC's on the other hand are things that should be looked at more like a parameter sent in, like the --from param. Aaron Korver 1 0 ---------------- Just my two bits. ------_=_NextPart_001_01C3DFB7.B05278F0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Odds and Ends

I'm with agreement with David on the fact that = CVSSPAM does one thing and does it well, that is it sends pretty = formatted HTML e-mails upon commits.  There are other pieces of = software out there to handle list management and they do that just fine = as well.

As far as other alternatives you may want to look at = the notify file in CVSROOT.  This file looks at the users file = (that is also in CVSROOT) and you might find a way to hook up CVSSpam = to this notify file.  The notify takes a param %s and goes through = the users file replacing the name of the user with the user's e-mail = address.  How you can hook these two together I don't know off the = top of my head.

Finally, one might be able to use the log.pl script = that comes with cvs <cvs install dir>/contrib/log.pl  There = are some instructions for use in the comments of the file.

With the DEFAULT you can just use this if you are = sure that everything needs to go to one list or person.  If you = need to seperate the mails out then of course DEFAULT won't work to = well.

The suggestion for the CC: might be interesting but I = don't think it should be parsed from the log message.  The log = message for a CVS commit should be purely related to what is being = checked in.  If it fixes a bug it should say so.  If there is = a TODO it should say so.  These are in my mind legitamite things = to parse for and act upon.  But CC's on the other hand are things = that should be looked at more like a parameter sent in, like the --from = param.

Aaron Korver
1 0
----------------
Just my two bits.

------_=_NextPart_001_01C3DFB7.B05278F0-- From dave at badgers-in-foil.co.uk Wed Jan 21 10:42:51 2004 From: dave at badgers-in-foil.co.uk (David Holroyd) Date: Wed, 21 Jan 2004 10:42:51 +0000 Subject: [cvsspam-devel] RE: cvsspam-devel digest, Vol 1 #31 - 1 msg In-Reply-To: <200401202210.25239.radoeka@xs4all.nl> References: <0205C50D41B7D611AEA50002A537CEC2016597FB@DES10MS01> <200401192050.36609.radoeka@xs4all.nl> <20040120103927.GA24915@vhost.badgers-in-foil.co.uk> <200401202210.25239.radoeka@xs4all.nl> Message-ID: <20040121104251.GA11954@vhost.badgers-in-foil.co.uk> On Tue, Jan 20, 2004 at 10:10:25PM +0100, Richard Bos wrote: > The subscription administration should not only be done by me, but by others > as well and for this reason I think it would be good to administrate the > addesses in a seperate file (to protect the rather sensitive loginfo file). > I just test the following command sequence in loginfo: > DEFAULT $CVSROOT/CVSROOT/collect_diffs.rb --from $USER@radoeka.nl > `$CVSROOT/CVSROOT/tolist default` %{sVv} > > TEST/CVSROOT> cat tolist > sed 's,^,--to ,' $CVSROOT/CVSROOT/subs/$1 | tr "\n" " " > > The file default contains the emailaddresses and this file can be safely > maintained by others (via cvs ofcourse). It's a nice solution -- it lets you do what you want, but is external to CVSspam itself. Another way to implement this would be to supply a custom script to $sendmail_prog in the config file. That would require a different config file for every entry in loginfo, though, which is worse than the solution you've already implemented :) > The above seem to work and it is exactly what I want. However, in > contradiction as what you stated I still think that it would be nice to have > an argument --tolist available doing the above ... ;) But now with the > algorithm above there is not much need for you to add to cvsspam... > > BTW. I tried to add the --tolist argument to cvsspam and I wundered how I > should read in the email addresses from the file to store them in the > recipients array. Parsing of the arguments went fine. The idiom in ruby is something like this, I think, File.open("/path/name") do |io| io.each do |line| # (IIRC, ruby removes the end-of-line string from each record) $recipients << line end end (You can also say, io = File.new("/path/name") # ... io.close but the first construction avoids the need for explicitly closing the file, and so is a bit neater.) > During the trial above I discovered to you use the variable '$passthoughArgs = > Array.new' in collrect_diffs. Isn't that a typo, shouldn't it be > $passthroughArgs (with an 'r')? Yep, that's a typo. I've corrected it in CVS. Thanks Richard! dave From dave at badgers-in-foil.co.uk Wed Jan 21 11:19:11 2004 From: dave at badgers-in-foil.co.uk (David Holroyd) Date: Wed, 21 Jan 2004 11:19:11 +0000 Subject: [cvsspam-devel] Questions about cvsspam.conf commitinfo In-Reply-To: <200401202218.58883.radoeka@xs4all.nl> References: <200401192108.41150.radoeka@xs4all.nl> <20040120111228.GB24915@vhost.badgers-in-foil.co.uk> <200401202218.58883.radoeka@xs4all.nl> Message-ID: <20040121111911.GB11954@vhost.badgers-in-foil.co.uk> On Tue, Jan 20, 2004 at 10:18:58PM +0100, Richard Bos wrote: > Op dinsdag 20 januari 2004 12:12, schreef David Holroyd: > > > Looking at it again I still think that the default line should be > > > sufficient and that an additional line is only needed when another script > > > is required for record_lastdir.rb, isn't it? ?I ask this as the > > > documentation that comes with cvsspam stated the following: > > > "The expression you use to select the project (the first thing on the > > > line) must be the same in commitinfo and loginfo." > > > > If you leave DEFAULT in commitinfo but keep module specific matches in > > loginfo, you should get email as expected. ?You'll also get temporary > > files hanging around after you commit to projects that don't have a match > > in loginfo (the files can only be deleted from the loginfo-hook). > > Forgive me to ask: why can't the temporary files (dir) be removed from the > loginfo-hook if the loginfo does not have the same regular expression? > Do record_lastdir.rb and cvsspam/collect_diff don't share the same tmp dir? > Is the directory not communicated between the 2? This is only a problem if there are any modules that *aren't* matched by a rule in loginfo. (For instance, if your loginfo matches the commitinfo you posted in a previous message, there's no rule matching the CVSROOT module.) After a little more thought, I can see a way around this. We could implement a special --cleanup-only argument for collect_diffs, so your loginfo could look like, ^proj_one/ collect_diffs.rb ... ^proj_two/ collect_diffs.rb ... ^proj_three/ collect_diffs.rb ... DEFAULT collect_diffs.rb --cleanup-only This way, the DEFAULT line can delete the temporary files that are left. However, maybe it's less effort to just ensure that when the commitinfo causes record_lastdir.rb to be invoked for a particular commit, that collect_diffs.rb is also invoked in every case? Does that makes sense? dave From dave at badgers-in-foil.co.uk Wed Jan 21 11:27:18 2004 From: dave at badgers-in-foil.co.uk (David Holroyd) Date: Wed, 21 Jan 2004 11:27:18 +0000 Subject: [cvsspam-devel] Questions about cvsspam.conf commitinfo In-Reply-To: <20040121111911.GB11954@vhost.badgers-in-foil.co.uk> References: <200401192108.41150.radoeka@xs4all.nl> <20040120111228.GB24915@vhost.badgers-in-foil.co.uk> <200401202218.58883.radoeka@xs4all.nl> <20040121111911.GB11954@vhost.badgers-in-foil.co.uk> Message-ID: <20040121112718.GC11954@vhost.badgers-in-foil.co.uk> On Wed, Jan 21, 2004 at 11:19:11AM +0000, David Holroyd wrote: > This way, the DEFAULT line can delete the temporary files that are left. Ah -- I expect you already have DEFAULT lines in both commitinfo and loginfo, eh? I that case it really doesn't matter; having a single entry, DEFAULT, in commitinfo will be sufficient :) dave From richard.bos at xs4all.nl Wed Jan 21 21:25:22 2004 From: richard.bos at xs4all.nl (Richard Bos) Date: Wed, 21 Jan 2004 22:25:22 +0100 Subject: [cvsspam-devel] RE: cvsspam-devel digest, Vol 1 #31 - 1 msg In-Reply-To: <20040121104251.GA11954@vhost.badgers-in-foil.co.uk> References: <0205C50D41B7D611AEA50002A537CEC2016597FB@DES10MS01> <200401202210.25239.radoeka@xs4all.nl> <20040121104251.GA11954@vhost.badgers-in-foil.co.uk> Message-ID: <200401212225.22007.radoeka@xs4all.nl> Op woensdag 21 januari 2004 11:42, schreef David Holroyd: > On Tue, Jan 20, 2004 at 10:10:25PM +0100, Richard Bos wrote: > > The subscription administration should not only be done by me, but by > > others as well and for this reason I think it would be good to > > administrate the addesses in a seperate file (to protect the rather > > sensitive loginfo file). I just test the following command sequence in > > loginfo: > > DEFAULT $CVSROOT/CVSROOT/collect_diffs.rb --from $USER@radoeka.nl > > `$CVSROOT/CVSROOT/tolist default` %{sVv} > > > > TEST/CVSROOT> cat tolist > > sed 's,^,--to ,' $CVSROOT/CVSROOT/subs/$1 | tr "\n" " " > > > > The file default contains the emailaddresses and this file can be safely > > maintained by others (via cvs ofcourse). > > It's a nice solution -- it lets you do what you want, but is external to > CVSspam itself. > > > The above seem to work and it is exactly what I want. However, in > > contradiction as what you stated I still think that it would be nice to > > have an argument --tolist available doing the above ... ;) But now with > > the algorithm above there is not much need for you to add to cvsspam... I showed it today to someone else, who administrates the cvs repository too and he likes this way of working. It is very easy to work with there is no other application involved, with yet another set of password, commands, etc. And still it is very light, it is flexible and it does the job exactly the way we want it. The only drawback is the way I have to inplement it, with the external 'tolist' script. I hope that one day the --tolist argument is just part of cvsspam! 1 remark about the solution I used: it is not possible to stored the file with email addresses in a seperate directory under $CVSROOT/CVSROOT as those files are not handled as administrative files (checkoutlist) by cvs. -- Richard From richard.bos at xs4all.nl Wed Jan 21 21:32:05 2004 From: richard.bos at xs4all.nl (Richard Bos) Date: Wed, 21 Jan 2004 22:32:05 +0100 Subject: [cvsspam-devel] Questions about cvsspam.conf commitinfo In-Reply-To: <20040121112718.GC11954@vhost.badgers-in-foil.co.uk> References: <200401192108.41150.radoeka@xs4all.nl> <20040121111911.GB11954@vhost.badgers-in-foil.co.uk> <20040121112718.GC11954@vhost.badgers-in-foil.co.uk> Message-ID: <200401212232.05400.radoeka@xs4all.nl> Op woensdag 21 januari 2004 12:27, schreef David Holroyd: > On Wed, Jan 21, 2004 at 11:19:11AM +0000, David Holroyd wrote: > > This way, the DEFAULT line can delete the temporary files that are left. > > Ah -- I expect you already have DEFAULT lines in both commitinfo and > loginfo, eh? I that case it really doesn't matter; having a single > entry, DEFAULT, in commitinfo will be sufficient :) > > > dave Hi Dave, thanks for the confirmation. I'll change my commitinfo file, and keep an eye on the temp files. If it works okay, does that mean that the docu should describe this possible scenario? I mean this part: http://www.badgers-in-foil.co.uk/projects/cvsspam/cvsspam-doc.html#AEN41 And especially this line: The expression you use to select the project (the first thing on the line) must be the same in commitinfo and loginfo. It may also stated something like: The DEFAULT in commitinfo may be the lastdir script, without the need to have the other expressions (from loginfo) in the commitinfo file. -- Richard From richard.bos at xs4all.nl Wed Jan 21 21:46:04 2004 From: richard.bos at xs4all.nl (Richard Bos) Date: Wed, 21 Jan 2004 22:46:04 +0100 Subject: [cvsspam-devel] Odds and Ends In-Reply-To: <0205C50D41B7D611AEA50002A537CEC201659810@DES10MS01> References: <0205C50D41B7D611AEA50002A537CEC201659810@DES10MS01> Message-ID: <200401212246.04032.radoeka@xs4all.nl> Op woensdag 21 januari 2004 01:44, schreef Korver, Aaron: > I'm with agreement with David on the fact that CVSSPAM does one thing and > does it well, that is it sends pretty formatted HTML e-mails upon commits. > There are other pieces of software out there to handle list management and > they do that just fine as well. > > As far as other alternatives you may want to look at the notify file in > CVSROOT. This file looks at the users file (that is also in CVSROOT) and > you might find a way to hook up CVSSpam to this notify file. The notify > takes a param %s and goes through the users file replacing the name of the > user with the user's e-mail address. How you can hook these two together I > don't know off the top of my head. > > Finally, one might be able to use the log.pl script that comes with cvs > /contrib/log.pl There are some instructions for use in > the comments of the file. > > With the DEFAULT you can just use this if you are sure that everything > needs to go to one list or person. If you need to seperate the mails out > then of course DEFAULT won't work to well. Aaron, sorry to be rute: I don't want alternatives. As you said 'I want the best'! I really like cvsspam, I have used log.pl, and I moved it away. I think I have shown with the tolist script that a file holding recipients is a good alternative for a longer --to list, but one that is still too short for a emaillist. And the fun thing is that you do not need to use the argument, although it is there. You can still use the --to argument sending the commit/log emails to emaillist. > The suggestion for the CC: might be interesting but I don't think it should > be parsed from the log message. The log message for a CVS commit should be > purely related to what is being checked in. If it fixes a bug it should > say so. If there is a TODO it should say so. These are in my mind > legitamite things to parse for and act upon. But CC's on the other hand > are things that should be looked at more like a parameter sent in, like the > --from param. It is a 1 time CC: to be determined by the person that is committing and not the cvs admin. Your proposal for a --from is in this respect out of scope. In think that this a vey legimate thing to do. A respectable open source project as kde does this for example. If a bug is fixed they email their bug system (bugzilla), using the CCMAIL: option in the log message and the bug is closed at the same time the patch is committed. I would like to let people know that I solved a bug that they reported. As those people are not on the cvsspam emaillist, the CCMAIL possibility would be a superb funcionality to inform the bug reporters! -- Richard From Aaron.Korver at Fiserv.com Thu Jan 22 18:12:06 2004 From: Aaron.Korver at Fiserv.com (Korver, Aaron) Date: Thu, 22 Jan 2004 12:12:06 -0600 Subject: [cvsspam-devel] Odds and Ends v2 Message-ID: <0205C50D41B7D611AEA50002A537CEC201659824@DES10MS01> This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C3E113.3E2B28F0 Content-Type: text/plain; charset="iso-8859-1" 1 remark about the solution I used: it is not possible to stored the file with email addresses in a seperate directory under $CVSROOT/CVSROOT as those files are not handled as administrative files (checkoutlist) by cvs. You need to add the list to the checkoutlist file in CVSROOT in order to tell cvs that it is an administrative file. It is a 1 time CC: to be determined by the person that is committing and not the cvs admin. Your proposal for a --from is in this respect out of scope. In think that this a vey legimate thing to do. A respectable open source project as kde does this for example. If a bug is fixed they email their bug system (bugzilla), using the CCMAIL: option in the log message and the bug is closed at the same time the patch is committed. I would like to let people know that I solved a bug that they reported. As those people are not on the cvsspam emaillist, the CCMAIL possibility would be a superb funcionality to inform the bug reporters! I have used CVSSpam for about a year now and contributed to it. As well as using bugzilla for about two years. Again I will state that IMHO I agree with David's first comment in that from an architectural point it is better to not bloat CVSSpam and let the different projects do what they do best. For bugzilla if you solve a bug and they really care about it, then they should be added to the CC list for bugzilla. With kde I believe that they use the bugzilla's mail front-end in which you can send e-mails to bugzilla and bugzilla knows what to do with it. From my experience bug reporters are customers or business analysts who don't care one bit about how the bug was fixed, just if it was fixed or not. Hence they add themselves to the CC list for bugzilla and bugzilla does what it does best, it notifies people who care about the bug. CVSSpam does what it does best, it notifies people who care about the code change. ------_=_NextPart_001_01C3E113.3E2B28F0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Odds and Ends v2

1 remark about the solution I used:  it is not = possible to stored the file
with email addresses in a seperate directory under = $CVSROOT/CVSROOT as those
files are not handled as administrative files = (checkoutlist) by cvs.

<response>
You need to add the list to the checkoutlist file in = CVSROOT in order to tell cvs that it is an administrative file.
<end response>

It is a 1 time CC: to be determined by the person = that is committing and not
the cvs admin.  Your proposal for a --from is = in this respect out of scope.
In think that this a vey legimate thing to = do.
A respectable open source project as kde does this = for example.  If a bug is
fixed they email their bug system (bugzilla), using = the CCMAIL: option in the
log message and the bug is closed at the same time = the patch is committed.
I would like to let people know that I solved a bug = that they reported.  As
those people are not on the cvsspam emaillist, the = CCMAIL possibility would
be a superb funcionality to inform the bug = reporters!

<response>
I have used CVSSpam for about a year now and = contributed to it.  As well as using bugzilla for about two = years.  Again I will state that IMHO I agree with David's first = comment in that from an architectural point it is better to not bloat = CVSSpam and let the different projects do what they do best.  For = bugzilla if you solve a bug and they really care about it, then they = should be added to the CC list for bugzilla.  With kde I believe = that they use the bugzilla's mail front-end in which you can send = e-mails to bugzilla and bugzilla knows what to do with it.  From = my experience bug reporters are customers or business analysts who = don't care one bit about how the bug was fixed, just if it was fixed or = not.  Hence they add themselves to the CC list for bugzilla and = bugzilla does what it does best, it notifies people who care about the = bug.  CVSSpam does what it does best, it notifies people who care = about the code change.

<end response>

------_=_NextPart_001_01C3E113.3E2B28F0-- From richard.bos at xs4all.nl Thu Jan 22 21:24:33 2004 From: richard.bos at xs4all.nl (Richard Bos) Date: Thu, 22 Jan 2004 22:24:33 +0100 Subject: [cvsspam-devel] RE: cvsspam-devel digest, Vol 1 #31 - 1 msg In-Reply-To: <20040121104251.GA11954@vhost.badgers-in-foil.co.uk> References: <0205C50D41B7D611AEA50002A537CEC2016597FB@DES10MS01> <200401202210.25239.radoeka@xs4all.nl> <20040121104251.GA11954@vhost.badgers-in-foil.co.uk> Message-ID: <200401222224.33086.radoeka@xs4all.nl> --Boundary-00=_R+DEAtuFUm41XHL Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Op woensdag 21 januari 2004 11:42, schreef David Holroyd: > > TEST/CVSROOT> cat tolist > > sed 's,^,--to ,' $CVSROOT/CVSROOT/subs/$1 | tr "\n" " " > > > > The file default contains the emailaddresses and this file can be safely > > maintained by others (via cvs ofcourse). > > It's a nice solution -- it lets you do what you want, but is external to > CVSspam itself. > > Another way to implement this would be to supply a custom script to > $sendmail_prog in the config file. =A0That would require a different > config file for every entry in loginfo, though, which is worse than > the solution you've already implemented :) > > > The above seem to work and it is exactly what I want. =A0However, in > > contradiction as what you stated I still think that it would be nice to > > have an argument --tolist available doing the above ... ;) =A0But now w= ith > > the algorithm above there is not =A0much need for you to add to cvsspam= =2E.. > > > > BTW. I tried to add the --tolist argument to cvsspam and I wundered how= I > > should read in the email addresses from the file to store them in the > > recipients array. =A0Parsing of the arguments went fine. > > The idiom in ruby is something like this, I think, > > =A0 File.open("/path/name") do |io| > =A0 =A0 io.each do |line| > =A0 =A0 =A0 # (IIRC, ruby removes the end-of-line string from each record) > =A0 =A0 =A0 $recipients << line > =A0 =A0 end > =A0 end Hello Dave, your idiom was the hit on the nail. With your example I have been able to= =20 extend cvsspam with --tolist support. Diff attached, it is not much code = I=20 therefor really hope that you'll incorperate it into cvsspam. =20 I consider this a superiour solution compared to the solution shown in the= =20 beginning of this email. =2D-=20 TIA, Richard --Boundary-00=_R+DEAtuFUm41XHL Content-Type: text/x-diff; charset="iso-8859-1"; name="tolist-diff.040122" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="tolist-diff.040122" diff -rupb cvsspam-0.2.8/collect_diffs.rb cvsspam-new/collect_diffs.rb --- cvsspam-0.2.8/collect_diffs.rb 2004-01-18 23:23:08.000000000 +0100 +++ cvsspam-new/collect_diffs.rb 2004-01-22 22:19:06.000000000 +0100 @@ -257,6 +257,7 @@ require 'getoptlong' opts = GetoptLong.new( [ "--to", "-t", GetoptLong::REQUIRED_ARGUMENT ], + [ "--tolist", "-T", GetoptLong::REQUIRED_ARGUMENT ], [ "--config", "-c", GetoptLong::REQUIRED_ARGUMENT ], [ "--debug", "-d", GetoptLong::NO_ARGUMENT ], [ "--from", "-u", GetoptLong::REQUIRED_ARGUMENT ] @@ -265,7 +266,7 @@ opts = GetoptLong.new( # arguments to pass though to 'cvsspam.rb' $passthoughArgs = Array.new opts.each do |opt, arg| - if ["--to", "--config", "--from"].include?(opt) + if ["--to", "--tolist", "--config", "--from"].include?(opt) $passthoughArgs << opt << arg end if ["--debug"].include?(opt) @@ -307,7 +308,8 @@ end if ARGV.length != 1 $stderr.puts "Expected arguments missing" $stderr.puts "* You shouldn't run collect_diffs by hand, but from a CVSROOT/loginfo entry *" - $stderr.puts "Usage: collect_diffs.rb [ --to ] [ --config ] %{sVv}" + $stderr.puts "Usage: collect_diffs.rb [ --to ] [ --config ]" + $stderr.puts " [ --tolist ] %{sVv}" $stderr.puts " (the sequence '%{sVv}' is expanded by CVS, when found in CVSROOT/loginfo)" exit end diff -rupb cvsspam-0.2.8/cvsspam.rb cvsspam-new/cvsspam.rb --- cvsspam-0.2.8/cvsspam.rb 2004-01-18 23:23:01.000000000 +0100 +++ cvsspam-new/cvsspam.rb 2004-01-22 22:20:26.000000000 +0100 @@ -886,11 +886,13 @@ $subjectPrefix = nil $files_in_subject = false; $smtp_host = nil $repository_name = nil +$tolist = nil require 'getoptlong' opts = GetoptLong.new( [ "--to", "-t", GetoptLong::REQUIRED_ARGUMENT ], + [ "--tolist", "-T", GetoptLong::REQUIRED_ARGUMENT ], [ "--config", "-c", GetoptLong::REQUIRED_ARGUMENT ], [ "--debug", "-d", GetoptLong::NO_ARGUMENT ], [ "--from", "-u", GetoptLong::REQUIRED_ARGUMENT ] @@ -901,16 +903,17 @@ opts.each do |opt, arg| $config = arg if opt=="--config" $debug = true if opt=="--debug" $from_address = arg if opt=="--from" + $tolist = arg if opt=="--tolist" end - if ARGV.length != 1 if ARGV.length > 1 $stderr.puts "extra arguments not needed: #{ARGV[1, ARGV.length-1].join(', ')}" else $stderr.puts "missing required file argument" end - puts "Usage: cvsspam.rb [ --to ] [ --config ] " + puts "Usage: cvsspam.rb [ --to ] [ --config ]" + puts " [ --tolist ] " exit(-1) end @@ -941,6 +944,23 @@ else blah("Config file '#{$config}' not found, ignoring") end +if $tolist != nil + + $tolist = "#{ENV['CVSROOT']}/CVSROOT/#{$tolist}" + + if FileTest.exists?($tolist) + + File.open($tolist) do |io| + io.each do |line| + $recipients << line.chop + end + end + + else + blah("tolist file '#{$tolist}' not found, ignoring") + end +end + if $recipients.empty? fail "No email recipients defined" end --Boundary-00=_R+DEAtuFUm41XHL-- From richard.bos at xs4all.nl Fri Jan 23 22:06:35 2004 From: richard.bos at xs4all.nl (Richard Bos) Date: Fri, 23 Jan 2004 23:06:35 +0100 Subject: [cvsspam-devel] Odds and Ends v2 In-Reply-To: <0205C50D41B7D611AEA50002A537CEC201659824@DES10MS01> References: <0205C50D41B7D611AEA50002A537CEC201659824@DES10MS01> Message-ID: <200401232306.35946.radoeka@xs4all.nl> Op donderdag 22 januari 2004 19:12, schreef Korver, Aaron: > 1 remark about the solution I used: it is not possible to stored the file > with email addresses in a seperate directory under $CVSROOT/CVSROOT as > those files are not handled as administrative files (checkoutlist) by cvs. > > > You need to add the list to the checkoutlist file in CVSROOT in order to > tell cvs that it is an administrative file. > That's what I have done. My conclusion from that is, that the file must be located in $CVSROOT. If the file is not there it won't be rebuild. > It is a 1 time CC: to be determined by the person that is committing and > not the cvs admin. Your proposal for a --from is in this respect out of > scope. In think that this a vey legimate thing to do. > A respectable open source project as kde does this for example. If a bug > is fixed they email their bug system (bugzilla), using the CCMAIL: option > in the > log message and the bug is closed at the same time the patch is committed. > I would like to let people know that I solved a bug that they reported. As > those people are not on the cvsspam emaillist, the CCMAIL possibility would > be a superb funcionality to inform the bug reporters! > > > I have used CVSSpam for about a year now and contributed to it. As well as > using bugzilla for about two years. Again I will state that IMHO I agree > with David's first comment in that from an architectural point it is better > to not bloat CVSSpam and let the different projects do what they do best. > For bugzilla if you solve a bug and they really care about it, then they > should be added to the CC list for bugzilla. With kde I believe that they > use the bugzilla's mail front-end in which you can send e-mails to bugzilla > and bugzilla knows what to do with it. From my experience bug reporters > are customers or business analysts who don't care one bit about how the bug > was fixed, just if it was fixed or not. Hence they add themselves to the > CC list for bugzilla and bugzilla does what it does best, it notifies > people who care about the bug. CVSSpam does what it does best, it notifies > people who care about the code change. > Alright we have a different point of view. Cvs does not necessarily have to host software. It could be documents, datafiles, web pages. And perhaps the changes are made without a bug database. Maybe just a request from someone. In such cases it would be handy to notify the change requester with the cvs log message that the changes has been made. -- Richard Bos Without a home the journey is endless