similar to: CVS forked into development/stable branches

Committed to CVS HEAD already. I think this is small enough change that it won't break anything too badly for v1.0, but I'd like to get some testing first. Here's a patch against branch_1_0 CVS and latest nightly snapshot (looks like they haven't been updating for a while, started building new a new one now): http://dovecot.org/patches/userdb-cache.diff Please try and tell me if

Some new features in CVS HEAD are: - v1.0 saves most of the data to dovecot.index.cache only when the client is FETCHing the messages. With mboxes the message headers are saved while parsing the mbox, which is almost the same thing. With CVS HEAD the dovecot.index.cache file is updated already when the new messages are being saved (with deliver or IMAP APPEND). This avoids reading the message

I've been meaning to switch away from CVS for a few years now, but I was never sure what I wanted to switch to, so I kept delaying it. I finally decided yesterday that Mercurial is pretty nice. The Mercurial repository is available from http://hg.dovecot.org/ (has a nice web interface). I wrote a small Mercurial mini-howto below. I'm not a Mercurial expert yet, so if you know better ways

I've been meaning to switch away from CVS for a few years now, but I was never sure what I wanted to switch to, so I kept delaying it. I finally decided yesterday that Mercurial is pretty nice. The Mercurial repository is available from http://hg.dovecot.org/ (has a nice web interface). I wrote a small Mercurial mini-howto below. I'm not a Mercurial expert yet, so if you know better ways

This line in configure.in src/plugins/mail-log/Makefile refers to a non existing direcory in the branch_1_0 tree, which breaks build. ciao Luca

The git master branch starts tracking Dovecot v2.3 development from now on. There are soon going to be several API changes there that might break plugins. If you wish to keep tracking latest v2.2.x development instead, switch to master-2.2 branch. The nightly releases at http://dovecot.org/nightly/ will also track v2.3 tree.

The git master branch starts tracking Dovecot v2.3 development from now on. There are soon going to be several API changes there that might break plugins. If you wish to keep tracking latest v2.2.x development instead, switch to master-2.2 branch. The nightly releases at http://dovecot.org/nightly/ will also track v2.3 tree.

I see that 1.0.5 is out. I thought that if I am tracking cvs v1.0.x I would always get the newest releases. However, I just did a fresh update and install from cvs stable and it reports as only being v1.0.3. Should I just be using the tarballs rather than the cvs -r 1_0? Or maybe my initial cvs was incorrect? Thanks! -- -M There are 10 kinds of people in this world: Those who can count in

To confuse Dovecot versioning even more, I've added "dovecot-stable" module into CVS. This is a version of Dovecot before the recent keyword changes but with several bugfixes backported to it. It's thought to be mostly stable. I intend to keep it updated with important bugfixes and with other simple bugfixes. Although I'm not sure if I'll make a large code base upgrade

http://dovecot.org/releases/dovecot-1.0.rc22.tar.gz http://dovecot.org/releases/dovecot-1.0.rc22.tar.gz.sig Found another bad bug in rc19 changes. Wonder why my imaptest catched the bug only in CVS HEAD but not in branch_1_0 even though both had it. Anyway, now the imaptest runs nicely for both, and I'm again optimistic that the bug count is low enough for v1.0 to be released soon :) BTW. My

http://dovecot.org/releases/dovecot-1.0.rc22.tar.gz http://dovecot.org/releases/dovecot-1.0.rc22.tar.gz.sig Found another bad bug in rc19 changes. Wonder why my imaptest catched the bug only in CVS HEAD but not in branch_1_0 even though both had it. Anyway, now the imaptest runs nicely for both, and I'm again optimistic that the bug count is low enough for v1.0 to be released soon :) BTW. My

I wasted too much time today doing this, but they do show a few interesting things: 1) mmap_disable=yes is faster than mmap_disable=no. I didn't expect this. I'm not yet sure why this is, but possibly because then it updates the mail index by reading the changes from dovecot.index.log, instead of reopening and re-mmaping dovecot.index. At least that's the biggest difference between

Woops... yep, that was the problem. Sorry. Bill On Mon, July 3, 2006 10:08 am, Timo Sirainen <tss at iki.fi> said: > Are you sure you're not just mixing changes to CVS HEAD and branch_1_0? > CVS HEAD was broken for days before this patch fixed it. > > On Mon, 2006-07-03 at 09:59 -0400, Bill Boebel wrote: >Fyi, after this patch I started seeing the error below: >

Hello, I've compiled nightly CVS snapshot and set it up to work with MySQL database: [...] auth default { mechanisms = plain user = root passdb sql { args = /usr/local/dovecot/etc/sql.conf } userdb sql { args = /usr/local/dovecot/etc/sql.conf } } sql.conf contains next line: connect = host=localhost

I received a TE406P card from Digium yesterday and have done several tests on it and cannot get it working reliably with any Stable release or even CVS v1.0. What are other people that are using the TE406P card using for an Asterisk version? I tried 1.2.0 beta1 and it seemed to function well except for an unrelated issue with the beta release where the manager interface chokes under

On Sat, March 17, 2007 10:51 pm, Timo Sirainen <tss at iki.fi> said: > Oh, and as for when the rewrite is in CVS, I'm not really sure. I'm > still wondering if I should put it there soon and make the release after > v1.0 be v2.0, or if I should first stabilize the current new CVS HEAD > features (which shouldn't take too long), do a v1.2 release and only > then

-----BEGIN PGP SIGNED MESSAGE----- Hash: RIPEMD160 bldg dovecot cvs branch_1_0 on osx, i'm seeing a sensitivity to order in protocol statements. e.g., on launch: THIS WORKS FINE: protocol lda { sendmail_path = /usr/local/exim/bin/exim ... plugin { quota = maildir:storage=10240 # 10 MB quota limit } } but, THIS DOES NOT protocol lda { ... plugin { quota =

Hello everyone, I recently stumbled upon an issue in the encoder of the v1.0 SDK. At the end of each encoding session a divide by zero (D=0) happens in bark_noise_hybridmp (psy.c:642). This causes a crash on Win9x systems (WinNT seems to handle this fine by using infinite as the result). My encoding code is almost identical to the encoder_example, so I'm reasonably sure that this is not a

As you can probably guess from my today's burst of activity, I'm no longer extremely busy. Actually it looks like for the next 3-4 weeks I don't have anything especially time consuming to do. So it's time to get Dovecot v1.0 released :) I've now read all the mails from this list again, and it looks like pretty much the only problems with rc10 was the mbox assert crash, which

Timo, Regarding: http://www.dovecot.org/list/dovecot/2005-January/006144.html I would like an estimate of where you are on the path to a released (dovecot-1.0). I have read your statement regarding the -stable series and am wondering when we see the first feature complete -beta of v1.0? Thank for your hard efforts. I have been a happy customer for about a year. Ray