Re: [SyncEvolution] merging "server-config" branch?
On Wed, 2009-11-25 at 18:41 +0000, Patrick Ohly wrote:
Old configs are used as they are, so no immediate action is needed
when
upgrading to master. In the nightly testing, configs are created anew
each night. I have updated the script which does that so that it works
with old and new SyncEvolution. At least that was the plan. It doesn't
seem to be working and because of choir rehearsals tonight I won't be
able to fix it before the night starts.
Duh! I forgot to implement the "search for config when no context is
given" feature. Added it to master so that we get a sane nightly test
run today:
commit e9fac137c5ce636cb5358947a511b0173c684c7c
Author: Patrick Ohly <patrick.ohly(a)intel.com>
Date: Wed Nov 25 23:08:57 2009 +0100
shared config: when no context is given, search for config
A string like "scheduleworld" without context specified via
@<context>
is meant to find such a config, regardless in which context it
is specified. The "default" context is meant to be searched first.
This patch adds this feature. It is done by a) determining whether a
context was specified explicitly and b) if not, searching the list of
configured peers.
Step a) requires a slightly modified normalizeConfigString()
implementation which tells the caller the context, even in the case
that @default gets stripped from the normalized form.
Step b) relies on sorting of the server list. Old-style configs or
configs in the default context come first and thus are found first, as
intended.
There's no explicit unit test for this. Running "client-test
Client::Sync" covers it (which is how the missing feature was
found...).
Please ignore nightly test
failures...
I aborted the first run and restarted it manually.
I haven't fixed compiler warnings and errors yet.
--
Best Regards, Patrick Ohly
The content of this message is my personal opinion only and although
I am an employee of Intel, the statements I make here in no way
represent Intel's position on the issue, nor am I authorized to speak
on behalf of Intel on this matter.