commit 3f540317d52bf8a4a04a3fbf1b1b791982ae5b7a
Author: Matthew Barnes <mbarnes@redhat.com>
Date:   Wed Mar 6 14:34:54 2013 -0500

    NEWS update for 3.6.4 release.

 NEWS |   35 ++++++++++++++++++++++++++++++++++-
 1 file changed, 34 insertions(+), 1 deletion(-)

commit f1a6b21f727c076a880ac73ee3b5ef5e1b527cdf
Author: Milan Crha <mcrha@redhat.com>
Date:   Thu Feb 28 19:08:31 2013 +0100

    Bug #694734 - Relative URI in Location on PUT confuses WebDAV

 addressbook/backends/webdav/e-book-backend-webdav.c |   13 ++++++++++---
 1 file changed, 10 insertions(+), 3 deletions(-)

commit 1f138d6516232b0860540c85427af84d8575130d
Author: Milan Crha <mcrha@redhat.com>
Date:   Wed Feb 27 20:10:17 2013 +0100

    Speed-up auto-completion results showing
    
    The results were postponed to show as long as there were new notifications
    about added contacts, which could take quite long for many matched items.
    This shows the results with smaller timeout and without postponing.

 libedataserverui/e-name-selector-entry.c |   33 ++++++++++++++++++++----------
 1 file changed, 22 insertions(+), 11 deletions(-)

commit 1e994d46ef5268cde76d6bf0c1f611864124a71c
Author: Matthew Barnes <mbarnes@redhat.com>
Date:   Fri Feb 22 06:55:59 2013 -0500

    e_source_registry_server_load_directory: Monitor failure is non-fatal.
    
    Directory monitoring is a nice-to-have feature, but is not supported in
    some contexts.  If we fail to create a GFileMonitor, leave a breadcrumb
    on the console to indicate something whent wrong, but don't return an
    error status.  That would cause the whole registry process to terminate.
    
    (cherry picked from commit af31c05e026bf9b7881ddc9adfa29d78e29766c0)

 libebackend/e-source-registry-server.c |   38 +++++++++++++++++++++++---------
 1 file changed, 28 insertions(+), 10 deletions(-)

commit d64269932c0824164f8b52d5bee325e412962a4a
Author: Milan Crha <mcrha@redhat.com>
Date:   Thu Feb 21 12:55:09 2013 +0100

    Bug #694223 - The "message-location" search never matches on IMAP+

 camel/camel-folder-search.c |   37 ++++++++++++++++++++++++++++++++-----
 1 file changed, 32 insertions(+), 5 deletions(-)

commit b3cfe67e57ff259cc410210eacbe7a99a87a9413
Author: Milan Crha <mcrha@redhat.com>
Date:   Wed Feb 20 14:28:08 2013 +0100

    Local Delivery not updated on start and missing Receiving Options page
    
    This was reported at Red Hat's bugzilla:
    https://bugzilla.redhat.com/show_bug.cgi?id=910252
    
    To have this fully working, users should edit the account and save
    the changes (even when not done any) by clicking the OK button
    in the account editor, thus the source will receive its extension
    and the next start the account will be recognized and auto-updated.

 camel/providers/local/camel-local-provider.c |    6 +++++-
 1 file changed, 5 insertions(+), 1 deletion(-)

commit 2cf90ed3ae1316f2d10f7b06fb34db84964f939b
Author: Milan Crha <mcrha@redhat.com>
Date:   Wed Feb 20 13:51:04 2013 +0100

    Do not use SSL_V2_COMPATIBLE_HELLO by default
    
    Zarafa server with disabled SSL v2 rejects connection when
    SSL v2 compatible hello is sent, thus disabled this by default.
    After all, SSL v3 should be used in general these days anyway.
    
    Use environment variable CAMEL_SSL_V2_HELLO=1 in case your server
    requires the old behavior.

 camel/camel-tcp-stream-ssl.c |   11 ++++++++++-
 1 file changed, 10 insertions(+), 1 deletion(-)

commit 035a1281a723c9e4e67f04eeced4420587d3620a
Author: Matthew Barnes <mbarnes@redhat.com>
Date:   Tue Feb 19 09:22:46 2013 -0500

    source_remove_sync: Fail gracefully when given a scratch source.
    
    Apparently e_dbus_object_get_source_removable() does not check its
    argument for NULL, and scratch sources have no internal EDBusObject.
    
    (cherry picked from commit a8eb939af5623eeb4b5fe24cfcde022d954f4d17)

 libedataserver/e-source.c |   20 ++++++++++++--------
 1 file changed, 12 insertions(+), 8 deletions(-)

commit fc24a7a7876de42b01ec49a3d9d8e48abcf426be
Author: Matthew Barnes <mbarnes@redhat.com>
Date:   Tue Feb 19 09:18:47 2013 -0500

    source_write_sync: Fail gracefully when given a scratch source.
    
    Apparently e_dbus_object_get_source_writable() does not check its
    argument for NULL, and scratch sources have no internal EDBusObject.
    
    (cherry picked from commit 8797493a7d211ec960e03cb8fcd9653220b6fa43)

 libedataserver/e-source.c |   20 ++++++++++++--------
 1 file changed, 12 insertions(+), 8 deletions(-)

commit 64f88a522448daf15d21ef3149cdf1029821ae8b
Author: Patrick Ohly <patrick.ohly@intel.com>
Date:   Thu Feb 14 16:04:14 2013 +0100

    ebook: avoid repeatedly creating GSettings in e_book_client_is_self
    
    When receiving the complete address book, a client has to use
    e_book_client_is_self() on every EContact to find the one which is the
    "self" contact. Calling e_book_client_get_self() instead does not
    work, because that would create the self contact if none exists (not
    desired for an app which just reads!).
    
    The problem with e_book_client_is_self() is that it creates and
    destroys a GSettings instance for the self UID each time the method is
    called. In addition to reading the value over and over again, this
    also triggers two D-Bus messages (AddMatch and RemoveMatch) - clearly
    bad for performance.
    
    To solve this problem, this patch caches the GSettings instance in a
    static variable. It is protected by a mutex, to keep the function
    thread-safe. The downside is that the instance is never going to be
    freed.
    
    It would be better to attach the GSettings instance to the EBookClient
    instance, but because e_book_client_is_self() doesn't get a pointer to
    that, this is not possible without an API change.

 addressbook/libebook/e-book-client.c |   14 +++++++++++---
 1 file changed, 11 insertions(+), 3 deletions(-)

commit 613e568a911900edc5d0fb5fa647c56aea18dbb8
Author: Milan Crha <mcrha@redhat.com>
Date:   Wed Feb 13 18:44:48 2013 +0100

    [CalDAV] Try to search for event when not in local cache
    
    CalDAV backend depends on local cache when a client ask for an event,
    which is usually fine, but when it comes to a meeting invitations,
    with which the server can add event to the calendar on its own,
    the invitation might not be found in the cache, thus try whether
    it's available on the remote machine, before reporting Object Not Found.

 calendar/backends/caldav/e-cal-backend-caldav.c |  310 ++++++++++++++++++-----
 1 file changed, 240 insertions(+), 70 deletions(-)

commit 147c817dd31ddee0ee097aa58ac3489c4d918f64
Author: Matthew Barnes <mbarnes@redhat.com>
Date:   Fri Feb 8 14:08:00 2013 -0500

    G_PRIORITY_HIGH_IDLE is sufficient to beat GTK+ redraws.
    
    GTK+ uses (G_PRIORITY_HIGH_IDLE + 20) for redrawing operations, which is
    actually a slightly lower priority than G_PRIORITY_HIGH_IDLE.  Therefore
    for our purpose, G_PRIORITY_HIGH_IDLE is sufficient.
    
    (cherry picked from commit 820dcf6cfc43265c6376f15d983381c3087a5d20)

 calendar/libecal/e-cal.c   |    6 ++++--
 camel/camel-folder.c       |   14 ++++++--------
 camel/camel-imapx-server.c |    6 ++++--
 camel/camel-service.c      |    5 ++---
 camel/camel-session.c      |    5 ++---
 camel/camel-store.c        |   28 ++++++++++++----------------
 camel/camel-subscribable.c |   14 ++++++--------
 7 files changed, 36 insertions(+), 42 deletions(-)

commit 03fcc5f17581b6b1b50a11bd46cc46ddb4289391
Author: Milan Crha <mcrha@redhat.com>
Date:   Fri Feb 8 17:34:48 2013 +0100

    Add comments around g_idle_add() changes

 calendar/libecal/e-cal.c           |    1 +
 camel/camel-folder.c               |    4 ++++
 camel/camel-imapx-server.c         |    1 +
 camel/camel-service.c              |    2 ++
 camel/camel-session.c              |    2 ++
 camel/camel-store.c                |    8 ++++++++
 camel/camel-subscribable.c         |    4 ++++
 libedataserver/e-gdbus-templates.c |    4 +++-
 8 files changed, 25 insertions(+), 1 deletion(-)

commit 9e0e08e201f853239fe02b7e694d3e1eac770e47
Author: Michel Dänzer <michel@daenzer.net>
Date:   Fri Feb 8 12:07:39 2013 +0100

    Bug #683867 - Schedule actions with higher idle priority

 calendar/libecal/e-cal.c           |    2 +-
 camel/camel-folder.c               |    8 ++++----
 camel/camel-imapx-server.c         |    2 +-
 camel/camel-service.c              |    2 +-
 camel/camel-session.c              |    2 +-
 camel/camel-store.c                |   16 ++++++++--------
 camel/camel-subscribable.c         |    8 ++++----
 libedataserver/e-gdbus-templates.c |    2 +-
 8 files changed, 21 insertions(+), 21 deletions(-)

commit 20aefc8b9eaa1bb57c5d2d829343107e0684b471
Author: Matthew Barnes <mbarnes@redhat.com>
Date:   Fri Feb 8 07:00:43 2013 -0500

    Revert "Bug #683867 - Schedule actions with higher idle priority"
    
    This reverts commit b6f0db12e7b2505b08ac0683c1d0d28d4a050ef3.
    
    The commit contains not a single comment as to why these custom priority
    values are being used.  The rationale needs to be documented in the code,
    either at each call point or preferably at a centralized priority value
    definition.

 calendar/libecal/e-cal.c           |    2 +-
 camel/camel-folder.c               |    8 ++++----
 camel/camel-imapx-server.c         |    2 +-
 camel/camel-service.c              |    2 +-
 camel/camel-session.c              |    2 +-
 camel/camel-store.c                |   16 ++++++++--------
 camel/camel-subscribable.c         |    8 ++++----
 libedataserver/e-gdbus-templates.c |    2 +-
 8 files changed, 21 insertions(+), 21 deletions(-)

commit b6f0db12e7b2505b08ac0683c1d0d28d4a050ef3
Author: Michel Dänzer <michel@daenzer.net>
Date:   Fri Feb 8 12:07:39 2013 +0100

    Bug #683867 - Schedule actions with higher idle priority

 calendar/libecal/e-cal.c           |    2 +-
 camel/camel-folder.c               |    8 ++++----
 camel/camel-imapx-server.c         |    2 +-
 camel/camel-service.c              |    2 +-
 camel/camel-session.c              |    2 +-
 camel/camel-store.c                |   16 ++++++++--------
 camel/camel-subscribable.c         |    8 ++++----
 libedataserver/e-gdbus-templates.c |    2 +-
 8 files changed, 21 insertions(+), 21 deletions(-)

commit 7145a1e240c85d2795398ca34cf7ed77ff61da31
Author: Milan Crha <mcrha@redhat.com>
Date:   Mon Feb 4 12:56:54 2013 +0100

    Bug #675287 - Spool file account doesn't show messages

 camel/providers/local/camel-mbox-summary.c |   12 +++++++-----
 1 file changed, 7 insertions(+), 5 deletions(-)

commit 3e7b237a6242a724830a412b95bbf8a80eb65d99
Author: Matthew Barnes <mbarnes@redhat.com>
Date:   Fri Feb 1 07:45:56 2013 -0500

    store_synchronize_sync(): Only sync subscribed folders.
    
    I recently added a Gmane (NNTP) account and have only a few newsgroup
    subscriptions.  Yet when I quit Evolution, Camel tries to synchronize
    all 13,872 newsgroups which literally takes days to complete.
    
    This adds a CAMEL_STORE_FOLDER_INFO_SUBSCRIBED flag to the request for
    a folder info tree while synchronizing + expunging.
    
    Note, CamelIMAPXStore will ignore the CAMEL_STORE_FOLDER_INFO_SUBSCRIBED
    flag if its "use-subscriptions" setting is FALSE, which is what we want.
    
    (cherry picked from commit 48b9d17d16be9f0ecb6066036cc83d08b3cca817)

 camel/camel-store.c |    1 +
 1 file changed, 1 insertion(+)

commit 71257132e4673566a26d8a0f9cb2e066367444bb
Author: Matthew Barnes <mbarnes@redhat.com>
Date:   Fri Feb 1 07:42:14 2013 -0500

    store_synchronize_sync() cleanups.
    
    (cherry picked from commit ad1b7cd145c5fa5443556c17ba6e9d701c531bb7)

 camel/camel-store.c |   38 +++++++++++++++++++++-----------------
 1 file changed, 21 insertions(+), 17 deletions(-)

commit d92dc8b420cd599143649dca65bed55a035dd5b6
Author: Milan Crha <mcrha@redhat.com>
Date:   Thu Jan 31 17:33:07 2013 +0100

    Bug #689476 - Slow composer open (ENameSelector object leaks)

 libedataserverui/e-name-selector.c |   10 ++++++++++
 1 file changed, 10 insertions(+)

commit 7c52fbd81093c1264e3d8aa6cdcf5c8bdc7b1772
Author: Milan Crha <mcrha@redhat.com>
Date:   Fri Jan 25 17:27:55 2013 +0100

    EGdbusTemplates: Address crash on operation cancel
    
    In situations when a synchronous operation was cancelled, but the response
    was already piled in main context the client could receive two replies, one
    from the reply, the other from the cancelled operation, effectively accessing
    invalid memory in the second response. This may address also other similar
    situations caused by cancelled operations.

 libedataserver/e-gdbus-templates.c |  104 +++++++++++++++++++++++++++++++-----
 1 file changed, 91 insertions(+), 13 deletions(-)

commit a84d0269dcd3978232cf5dce77ae4a6d7f6107fd
Author: Milan Crha <mcrha@redhat.com>
Date:   Tue Jan 22 20:44:41 2013 +0100

    Bug #692278 - LDAP backend mutex deadlock on finalize

 addressbook/backends/ldap/e-book-backend-ldap.c |   24 ++++++++++++++++-------
 1 file changed, 17 insertions(+), 7 deletions(-)

commit bbbeb5e67f98e2f7153685158ccd1bc4668b5185
Author: Matthew Barnes <mbarnes@redhat.com>
Date:   Mon Jan 21 14:36:40 2013 -0500

    Post-release version bump.

 configure.ac |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)