[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: spamd, greylisting and bad MTA's
- To: misc_(_at_)_openbsd_(_dot_)_org
- Subject: Re: spamd, greylisting and bad MTA's
- From: Fabio Olive Leite <fabio_(_dot_)_olive_(_at_)_gmail_(_dot_)_com>
- Date: Fri, 15 Apr 2005 10:03:03 -0300
- Mail-followup-to: misc_(_at_)_openbsd_(_dot_)_org
On Thu, Apr 14, 2005 at 04:04:49PM +0200, Rickard Borgmdster wrote:
> If I do "cvs update -r 1.74 spamd.c" only spamd.c is updateed (which
> probably is ok) but I thought that other files in the directory might have
> been updated too (such as grey.c or some).
Like Ted Unangst just pointed out, you can stick the whole directory
to the date when this fix was commited. This way you have to care less
about individual file changes.
At this point I think a good read of the cvs manpage is just what you
need to have the last chips fall into place. :-)
> So if I do "cvs update -r 1.74"
> the whole directory would be updated. Yes, if the rest of the files ID
> matched 1.74, which they do not. Do I have to update each file manually?
Yes, in CVS every file is versioned independently. You have to track
each file's version number if you want to achieve some special
combination of sources. But just like TedU said, you might as well
just point your spamd directory to the day after this fix was
commited. Timestamps end up working somewhat like "repository version
numbers" or "repository generations" in this case, provided every
commit is separated by at least a few seconds.
> And, how do I know which version of (example) grey.h ism concurrent with
> spamd.c 1.74?
Analyse the changes to spamd.c, check if changes to grey.h were done
at the same time, whatever. You have the source and the change
history, so you can figure it out. Or just point your entire spamd
directory to a good date that catches all.
I drowned in the universal pool of entropy
Eris has saved me, and she has set me free
EX SED LEX AWK YACC, E PLURIBUS UNIX, AMEM
Visit your host, monkey.org