SyncEvolution 1.1.1 did not build without this patch on S360, because
the source used an integer typedef which turned out to be incompatible
with size_t, although it should have the same size. Apparently the
compiler distinguishes between "unsigned int" and "unsigned long",
even if both have the same size.
One of them ("We don't know what this device...") was already
translated elsewhere. It might be that it is already translated in the
UI. The other ("Use these settings") was not and thus really showed up
as untranslated.
Running gen-autotools.sh as part of "make distcheck" fails because the
source directory is read-only. It shouldn't be needed and wouldn't
replicate the same autotools files (due to the missing "git describe"
output), so disable running it unless the source directory contains a
.git repo.
"gen-autotools.sh" (invoked by "autogen.sh") is needed to create some
of the autotools .am and .in files. This is necessary to avoid
hard-coding certain lists of dirs (backends) and files (templates).
The generated makefiles updated themselves when these files were
modified, but not when files were added or removed.
This patch fixes that. It also avoids some code duplication. Instead
of adding explicit rules to the makefiles for the file dependencies,
now gen-autotools.sh is run on each "make all" or "make Makefile"
invocation. It modifies the generated files only if their content has
changed. The dependency rules for "Makefile.am" and "configure.in" are
constructed so that make re-checks their time stamps after running the
gen-autotools.sh script.
A nightly test run showed that process() was freeing memory
when called indirectly from restore(). The protection against
recursive processing wasn't working because m_processing wasn't
set by restore(). Added it to that and some other high-level
calls which might end up with a recursive call into process().
The test failed only because the test's own introduction text on
stdout ended up being redirected. Flushing it before running the
test avoids that.
The flushing was added to both the client runner (because some other
tests also accidentally redirected the output, and it should be
made visible right away) and to the "glib" test (because it shouldn't
depend on flushing in the runner).
An incomplete source config might already exist. Better set the source
type in all cases, to ensure that we really run with the right backend
and data format.
Just saying "foo = bar" is enough now. --sync-property and
--source-property are still accepted, in case that "foo" ever becomes
ambiguous (not the case right now).
The meaning of "type" was horribly complex and had effects on the
backend and the peer. It was impossible to specify the sync format to
be used for a specific peer independently of the local backend and its
format, so adding a peer to a context broke the context configuration
(BMC #1023).
This is now fixed by splitting "type" into four independent properties:
- backend = plugin which interfaces with the data
- databaseFormat = data format used inside backend, only relevant for file backend
- syncFormat = data format preferred when talking to peer
- forceSyncFormat = disable format auto-negotiation, use preferred format
With that split, it is now possible to specify the format in which the
file backend stores items independently of the format in which they
are exchanged with the peer.
Old configurations with "type" can still be read. The values specified
inside it are transparently mapped to the new properties. Command line
and D-Bus API users will only see the new properties.
The command line tool still accepts "type" as an alias for the four new
properties. Using that has the same disadvantage as before: it will modify
the context even if only modifying the peer was intended.
The D-Bus API accepts only the new properties. Clients using "type"
must be adapted to the new property names. Clients not using that
continue to run unchanged.
Writing into the configuration requires a migration of the peer config
*and* the context in which it is defined. That is necessary because
the new semantic (independent database format) cannot be stored in the
old format. The migration is handled by rewriting first the context,
then all peers defined inside it.
Other user-visible changes:
- updated help texts
- the canonical "backend" value for the file backend is just "file"
instead of the long "Files in one directory", which is now an alias
(used to be the other way around); done because "type = file"
was expanded to the long name, which was a bit unexpected and showed
how unintuitive the long name is
Internal changes:
- getMimeVersion() is still present, although it hasn't been used
for a long time; FileSyncSource::getMimeVersion() now derives
the version from the supported Mime types, in case that the
function will be needed again in the future
- setSourceType() with string as argument was replaced with one
taking a SourceType instance; to emulate the old behavior if
desired, construct SourceType from an old-style string
- ConfigProperty methods need to be virtual so that derived classes
like SourceBackendConfigProperty can generate content at runtime
(a recent commit broke that feature)
- File templates were stripped down to the essential properties,
with "type" replaced by the per-peer "syncFormat". "type" would
still have been accepted (so it is not necessary to adapt
syncevo-phone-config right away), but has the original
disadvantage of modifying "backend" and "databaseFormat".
First step towards removing "type". The parsing of the type string was
moved into SourceType. m_localType and comments were added to
illustrate how SourceType will be used in the future (not enabled
yet). getSourceTypeString() was removed because it was only needed for
error messages and will no longer be correct once "type" property is
gone.
Because of the shared source property name changes
(evolutionsource/user/password -> database*), mixing old and new
configs inside the same context is not possible. Bumped
CONFIG_CONTEXT_MIN_VERSION and CONFIG_CONTEXT_CUR_VERSION to reflect
that and added the necessary code for migrating a context and all
peers inside it.
This is triggered by a) an automatic config migration in release mode
and b) an explicit --migrate of *any peer inside the context* or of
the context itself.
There was a getContextName(), but no getPeerName(). Added. Required
renaming the existing getPeerName() to getUserPeerName(), with
setUserPeerName() renamed accordingly. The former is the internal
part of the config name, the latter the user-visible chosen name.
The list of read-only properties which can be ignored in SetConfig()
was incomplete. Also need to take into account the ones added for
Bluetooth templates.
When creating a config from scratch, the command line source properties
applying to the default source set in the template were ignored. That's
because createFilters() needs to know about all active sources, otherwise
it won't create the filters for them.
When running a command line failed, an assertion was raised without
ever showing the error output of the failed command line. Now it is
included as message text in the CPPUNIT_ASSERT_MESSAGE() exception.
This config extension makes it possible to send BDAY and REV in
extended format (with hyphens) by including subrule
EXTENDED-DATE-FORMAT. Not done by default.
Calling the parent logger may invoke flushing in LogRedirect. This
needs to be done before writing the log message which causes that
flushing, otherwise the order of lines in the -log.html file is
slightly wrong.
An additional parameter allows the caller to decide whether
LogRedirect writes into stdout (original behavior) or opens
a specific file. Useful for client-test, which can avoid
one layer of loggers that way.
It was already possible to keep known errors out of stdout with
the SYNCEVOLUTION_SUPPRESS_ERRORS env variable. Now the same is
also possible at runtime via addIgnoreError(). This is useful
for backends which know about some of their internal errors that
they might produce indirectly (tools or libs being called, etc.).
If --source-property was set while syncing, the intention was to only
apply (and thus potentially enable) the filter to active sources. If
no sources where specified on the command line, then the code looked
at the config to build that list.
That code must have been broken for a long time, because it had a ==
"disabled" check instead of != "disabled", thus enabling exactly the
wrong sources. Fixed.
Probably not relevant for old releases because it only applied to cases
where no source filter was set. That additional shortcut check was
removed when rewriting the property filters, so now it was found.
Now the @context or @peer@context suffix in sync and source properties
on the command line can be used to configure both sides of the sync
differently.
The new format of the property name in --sync-property is:
<name>[@<context>|@<peer>@<context>]
--source-property also allows a source name:
[<source>/]<name>[@<context>|@<peer>@<context>]
This allows to set source properties differently for different
sources in the same command line invocation. The @<context> or
@<peer>@<context> will be used to set properties differently for
main and target context in a local sync (not used yet).
The advantage of this grammar is that a string can be split purely based
on the syntax in PropertySpecifier::StringToPropSpec().
The patch itself is based on the idea of first collecting all of these
config property filters in a new case-insensitive hash structure,
FullProps in ConfigFilter.cpp/h, as part of parsing command line
parameters.
Then once specific filters for sync or sources are needed, they are
generated from FullProps by collecting all that apply, starting with
the ones with lowest priority and overwriting them with more important
(= more specific) ones. This also covers additional filters, like the
shared properties of the target context when printing a template.
Currently FullProps may contain arbitrary source and config
names. Typos are not detected, which is both hard to implement (which
names and configs are valid in the current invocation?) and also
forces users to be very specific (can't apply one set of filters to
different configs) - this is the same conflict of interest as in
"configure", which allows unknown --enable/disable parameters because
they might be relevant in a sub-configure script.
SyncConfig itself still only stores the filters which apply to it, not
the full set of overrides that the Cmdline has in its m_props. The
advantage is that the API remains the same (no change needed or done
in the syncevo-dbus-server). The disadvantage is that in a local
sync, no information is available about the properties applying to the
target context - probably needs to change.
The traditional normal form of a peer config in the @default context
did not contain that suffix. This is more readable for the user,
but has disadvantages:
- name is only unambigious if that config exists, otherwise
the config name "foo" might also be mapped to "foo@someothercontext"
- if both a context and a config name are allowed, a config
can only be detected if it has an explicit @ sign in its name
Therefore this patch adds an alternative normal form which always
has a context specifier.
Renaming "evolutionsource/user/password" to "database", "databaseUser",
"databasePassword" affects D-Bus API clients which depend on the old
names. No known clients use these properties, so making the change
is acceptable, but some caution is needed nevertheless.
This patch adds a validation step to SetConfig() that detects unknown
properties and top-level entries. "" for sync properties and
"source/<name>" for source properties are currently accepted,
everything else is rejected.
Property values are also checked in advance, compared to checking them
later as part of copying them. The exception raised now for invalid
values is a more specific org.syncevolution.InvalidCall.
While adding the validation step it was noticed that the description
of temporary settings in SetConfig() was incorrect: temporary changes
*do* affect the result of GetConfig(). Documentation fixed.
Temporary settings can be reset now with SetConfig(update=False,
temporary=True), something which wasn't allowed earlier.
The SetConfig() call did not prepare the config for writing. Therefore
the obligatory version check was missing for old configs and versions
weren't set in new configs.
This renames the legacy "evolutionsource/user/password" properties to
"database" and "databaseUser/Password". The justification is that
these properties are also used outside of the Evolution backends.
The change can be done now because the on-disk format has to be
changed anyway in a backward-incompatible way.
The CmdlineTest::testOldConfigure test covers reading an old-style
config.
The goal is to allow multiple names for properties. This will be used
to replace legacy names like "evolutionsource", but it could also be
used to allow abbreviations on the command line.
First the patch replaces the single ConfigProperty::m_name with a list
of names, of which the first one is the current name of the
property.
The name that is to be used depends on the node which is to be
manipulated: if it already has a property under an alias, that alias
is read and also written, so existing configuration continue to use
the old config name (avoids the problem of having to remove the old
name and insert the new one at the same spot in a .ini file). Old
configs continue to parse okay. Writing into node which has none of
the names set, as in migrating into a fresh config, uses the new
names.
Most of the patch deals with the removal of a single, unique name,
either by picking the name so that it matches a node, using the
default name or simply hard-coding a property name ("sync").
The command line accepts all aliases, then uses the main name for
overriding configuration options.
SyncConfig inherited "const char *" from the Funambol C++ API and some
other methods used the same approach for efficient access to plain
strings. However, this has the disadvantage that dynamically generated
strings cannot be returned. SyncConfig had to use an awkward
workaround with a local string cache.
This patch converts most of that code to a normal std::string return
value and removes the string cache.
Out-of-tree backends must be adapted, otherwise they won't compile.
