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 <[email protected]>
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.


_______________________________________________
SyncEvolution mailing list
[email protected]
http://lists.syncevolution.org/listinfo/syncevolution

Reply via email to