lp://qastaging/~slgeorge/isync/trunk
- Get this branch:
- bzr branch lp://qastaging/~slgeorge/isync/trunk
Branch merges
Branch information
Import details
This branch is an import of the HEAD branch of the Git repository at git://git.code.sf.net/p/isync/isync.
Last successful import was .
Updating branch...
Launchpad is processing new changes to this branch which will be available in a few minutes. Reload to see the changes.
Recent revisions
- 1208. By _0-
-
build: also consider builds off of git with `git clone --depth 1`
one case where this could happen is a shallow clone, purely for build
purposes. in source based distros, like gentoo, setting depth of the
clone to 1, globally, is a common configuration. this patch avoids that
those builds fail.Signed-off-by: Paymon MARANDI <email address hidden>
- 1207. By Oswald Buddenhagen <email address hidden>
-
accept zero-sized messages from IMAP
while such a thing is rather pointless, completely empty messages are
not forbidden. consequently, we should be able to deal with them, and
above all not crash. - 1206. By Behnam Lal <email address hidden>
-
mbsync-get-cert: add support for STARTTLS
nowadays, many servers offer STARTTLS on the default IMAP port 143
instead of (or in addition to) the traditional IMAP over SSL/TLS (IMAPS)
on port 993.this patch has been fixed up somewhat by the maintainer.
- 1205. By Oswald Buddenhagen <email address hidden>
-
make summary more concise
the verbose summary was actually hard to read due to the numbers getting
lost between the words.i considered highlighting the numbers using ansi escapes, but the
irregular structure would be still hard to parse, and the escapes would
be unsuitable for log files.also considered was clustering the numbers at the beginnings of the
lines, but that would result in a messy sentence structure.a proper tabular format would introduce a lot more spacing, and would be
a lot harder to implement for little tangible benefit.i tried just using the progress counter format, but with plain numbers
instead of the "x/y", but it looked kinda stupid.so instead use a slightly expanded, semi-tabular version of that, as
suggested by Akshay Hegde on the list. this format bears a risk of
exceeding 80 columns, and in log files the internal spacing looks kinda
out of place, but these should be minor issues in practice.amends a1a3313e.
REF: <email address hidden>
- 1204. By Oswald Buddenhagen <email address hidden>
-
fix crash when resuming message propagation with MaxMessages
the problem is triggered by the source-side message disappearing
after a transaction to propagate it was started and then interrupted.it seems tempting to centralize the null-check, but some of the other
branches are taken in situations where the relevant messages from the
source store have not been requested.no autotest, as our test suite does not support injecting changes before
resuming.amends 0089f49.
- 1203. By Oswald Buddenhagen <email address hidden>
-
fix omissions in making expiration target side configurable
amends 8566283c.
- 1202. By Oswald Buddenhagen <email address hidden>
-
do not let both-sided uidvalidity change deter us
the algorithm is symmetrical, comparing the msgids that belong to the
paired uids. so it doesn't matter for recovering one side if the other
side's uidvalidity also changed. it does however impact our ability to
say on which side the change was genuine.the pointless limitation was presumably a vestige from an earlier
iteration.amends 77acc26 and 594e60b.
- 1201. By Ludovico Gerardi <email address hidden>
-
remove stray closing brace from man page
amends 5d5e07eb.
- 1200. By Oswald Buddenhagen <email address hidden>
-
fix implicit listing of Maildir INBOX under Path
commit acd6b4b0 ("simplify/fix recursive maildir listing") argued that
listing INBOX when it is encountered while listing Path would be
unnecessary, as the caller would list it separately anyway if requested.
however, it is actually documented that Patterns will implicitly match
INBOX nested into Path. so revert that commit.REFMAIL: 20240818002409.
4c918eb4@ inari - 1199. By Oswald Buddenhagen <email address hidden>
-
improve reporting of failure to open previously present mailbox
tell explicitly that the box cannot be opened _any more_, so it's clear
that Delete, rather than Create, would apply.fwiw, it would be preferable to actually differentiate between absent
mailboxes and ones that fail to open for other reasons. but
unfortunately, IMAP doesn't report the difference (gmail has a
non-standard [NONEXISTENT] response code, though).
Branch metadata
- Branch format:
- Branch format 7
- Repository format:
- Bazaar repository format 2a (needs bzr 1.16 or later)