I am looking at HEAD branch, FetchMail version 1.9.
HEAD branch should be the newest right? But it seams to be 4 months old, hmmm.
I cannot select any v. 2.2 branch though?
Please tell me what is going on here. The code you supply can be found under
2.1_fcs.
But according to contributions patches MUST be made against HEAD branch and
then backported.
Does this mean that if I have a patch for this new fetchmail 1.9.2.1, I should
not make it against HEAD but against 2.1_fcs?
I think it is a "little" confusing, I believe there are good reasons to only
implement functional (and I regard a robustness enhancement as such) against
the HEAD branch, It will IMO make life easier for you comitters, when
non-comitters like myself, submit patches against the functionally superior
branch. Am I totally wrong in this impression? Then please enlighten me.
regards
S�ren
On Monday 15 September 2003 10:31, Steen Jansdal wrote:
> Soeren Hilmer wrote:
> > Okay, it looks like FetchMail has a check for this that goes like:
> >
> > // if we are already fetching then just return
> > if (fetching) return;
> > fetching = true;
> >
> > ...
> > fetching = false;
> >
> > May I suggest though the more robust scheme:
> > try {
> > // if we are already fetching then just return
> > if (fetching) return;
> > fetching = true;
> >
> > ...
> > } finally {
> > fetching = false;
> > }
> >
> > This will ensure that fetching is set to false, even if some runtime
> > exception is thrown, and thereby ensuring that FetchMail is actually
> > fetching after that.
> >
> > I read from the response mails to my original post, that because FetchPop
> > is being deprecated, the patches for that are not wanted, okay.
> > I just keep my local patched version until a time where I can make the
> > switch to FetchMail then.
> >
> > --S�ren
>
> I don't know what version you are looking at but in 2.2.0a10 it
> looks like:
>
> // if we are already fetching then just return
> if (isFetching())
> return;
>
> // Enter Fetching State
> try
> {
> setFetching(true);
>
>
> ...
>
> finally
> {
> // Ensure the dynamic accounts are thrown away
> resetDynamicAccounts();
>
> getLogger().info(
> getConfiguration().getFetchTaskName()
> + " fetcher completed fetches");
>
> // Exit Fetching State
> setFetching(false);
> }
>
> So it's a little more robust than you first listing, but
> could actually be more robust.
>
> Steen
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
--
S�ren Hilmer, M.Sc.
R&D manager Phone: +45 70 27 64 00
TietoEnator IT+ A/S Fax: +45 70 27 64 40
Ved Lunden 12 Direct: +45 87 46 64 57
DK-8230 �byh�j Email: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
