[Syncevolution-issues] [MeeGo Projects - Bug 7181] create @context configuration from scratch

http://bugs.meego.com/show_bug.cgi?id=7181 pohly <patrick.ohly(a)intel.com&gt; changed: What |Removed |Added ---------------------------------------------------------------------------- Status|ASSIGNED |RESOLVED Resolution| |FIXED --- Comment #1 from pohly <patrick.ohly(a)intel.com&gt; 2010-09-29 06:10:05 PDT --- (In reply to comment #0) That was because there was explicit code which tried a setSync(), which only makes sense when configuring a peer. That code is now conditional for peers. This should have been caught by testing, except that there was no unit test for this specific kind of command line. Added. While working on it, one question came up: which sources should be configured when creating a config with one or more source listed explicitly? Traditionally, all sources were configured, but only the listed one was enabled. This makes sense because users then can enable the source selectively, either during --run or with --configure without access to the original template. But for a context, the template is useless. IMHO it makes more sense to only create the "calendar" source in the command line above. That's what the code now does. Finally, what if a peer is configured inside a context which only has one source configured? Should the other sources be added with their default values? That's how it is done now, but I'm a bit uncertain about that behavior. commit cb67e29e0aebcc845ce87d9c807a8acd80135eb0 Author: Patrick Ohly <patrick.ohly(a)intel.com&gt; Date: Wed Sep 29 15:00:16 2010 +0200 command line: fixed configuring of context (BMC #7181) A context holds a set of source settings, without any peer-specific properties like "sync mode". The code for configuring such a context tried to set the sync mode and thus failed. This patch unifies the check for "configuring context" in one place. It also slightly modifies the set of sources which are configured: traditionally, all sources were configured, but only the listed ones were enabled. This makes sense because users then can enable the source selectively, either during --run or with --configure without access to the original template. For a context, there is no concept of a "disabled" source. Adding those makes no sense and thus is not done anymore. Configuring a single source in a new context, adding a second source and adding a peer is now tested in CmdlineTest::testConfigureSources. Note that this contains a hack to reflect the broken behavior in BMC fixed. -- Configure bugmail: http://bugs.meego.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are watching someone on the CC list of the bug.