1SYNCEVOLUTION(1) SYNCEVOLUTION(1)
2
6 SyncEvolution - synchronize personal information management data
7
9 Show available sources:
10 syncevolution
11 Show information about configuration(s):
13 syncevolution --print-servers|--print-configs|--print-peers
14 Show information about a specific configuration:
16 syncevolution --print-config [--quiet] <config> [main|<source>
17 ...]
18 List sessions:
20 syncevolution --print-sessions [--quiet] <config>
21 Show information about SyncEvolution:
23 syncevolution --help|-h|--version
24 Run a synchronization as configured:
26 syncevolution <config> [<source> ...]
27 Run a synchronization with properties changed just for this run:
29 syncevolution --run <options for run> <config> [<source> ...]
30 Restore data from the automatic backups:
32 syncevolution --restore <session directory> --before|--after
33 [--dry-run] <config> <source> ...
34 Modify a configuration:
36 syncevolution --configure <options> <config> [<source> ...]
37 syncevolution --remove|--migrate <options> <config>
38 List items:
40 syncevolution --print-items <config> <source>
41 Export item(s):
43 syncevolution [--delimiter <string>] --export <dir>|<file>|-
44 <config> <source> [<luid> ...]
45 Add item(s):
47 syncevolution [--delimiter <string>|none] --import
48 <dir>|<file>|- <config> <source>
49 Update item(s)
51 syncevolution --update <dir> <config> <source> syncevolution
52 [--delimiter <string>|none] --update <file>|- <config> <source>
53 <luid> ...
54 Remove item(s):
56 syncevolution --delete-items <config> <source> (<luid> ... | *)
57
59 This text explains the usage of the SyncEvolution command line.
60 SyncEvolution synchronizes personal information management (PIM) data
62 such as contacts, appointments, tasks and memos using the Synthesis
63 sync engine, which provides support for the SyncML synchronization pro‐
64 tocol.
65 SyncEvolution synchronizes with SyncML servers over HTTP and with
67 SyncML capable phones locally over Bluetooth (new in 1.0). Plugins pro‐
68 vide access to the data which is to be synchronized. Binaries are
69 available for Linux desktops (synchronizing data in GNOME Evolution,
70 with KDE supported indirectly already and Akonadi support in develop‐
71 ment), for MeeGo (formerly Moblin) and for Maemo 5/Nokia N900. The
72 source code can be compiled for Unix-like systems and provides a frame‐
73 work to build custom SyncML clients or servers.
74
76 The <config> and the <source> strings are used to find the configura‐
77 tion files which determine how synchronization is going to proceed.
78 Each source corresponds to one local address book, calendar, task list
79 or set of memos and the corresponding database on the peer. Depending
80 on which parameters are given, different operations are executed.
81 Starting with SyncEvolution 1.0, <config> strings can have different
83 meanings. Typically, a simple string like memotoo refers to the config‐
84 uration for that peer, as it did in previous releases. A peer is either
85 a SyncML server (the traditional usage of SyncEvolution) or a client
86 (the new feature in 1.0).
87 Each peer configuration exists inside a specific context, typically the
89 @default context. All peers in the same context share some parts of
90 their configuration, for example, which local databases are to be syn‐
91 chronized. In that sense, a configuration context can be seen as a set
92 of local databases plus the peer configurations that are synchronized
93 against those databases.
94 The peer-independent properties of a source can be configured by giving
96 the context name as <config> parameter ("@default addressbook"). Opera‐
97 tions manipulating the local data also accept the context name.
98 When different peers are meant to synchronize different local data‐
100 bases, then different contexts have to be used when setting up the
101 peers by appending a context name after the at sign, as in memo‐
102 too2@other-context. Later on, if memotoo2 is unique, the @other-context
103 suffix becomes optional.
104 Sometimes it is also useful to change configuration options of a con‐
106 text, without modifying a specific peer. This can be done by using
107 @default (or some other context name) without anything before the at
108 sign. The empty string "" is the same as @default.
109 syncevolution
111 If no arguments are given, then SyncEvolution will list all available
113 data sources regardless whether there is a configuration file for them
114 or not. The output includes the identifiers which can then be used to
115 select those sources in a configuration file. For each source one can
116 set a different synchronization mode in its configuration file.
117 syncevolution <config>
119 Without the optional list of sources, all sources which are enabled in
121 their configuration file are synchronized.
122 syncevolution <config> <source> ...
124 Otherwise only the ones mentioned on the command line are active. It is
126 possible to configure sources without activating their synchronization:
127 if the synchronization mode of a source is set to disabled, the source
128 will be ignored. Explicitly listing such a source will synchronize it
129 in two-way mode once.
130 In SyncEvolution's predefined configuration templates, the following
132 names for sources are used. Different names can be chosen for sources
133 that are defined manually.
134 * addressbook: a list of contacts
136 * calendar: calendar *events*
137 * memo: plain text notes
138 * todo: task list
139 * calendar+todo: a virtual source combining one local "calendar" and
140 one "todo" source (required for synchronizing with some phones)
141 Progress and error messages are written into a log file that is pre‐
143 served for each synchronization run. Details about that is found in the
144 Automatic Backups and Logging section below. All errors and warnings
145 are printed directly to the console in addition to writing them into
146 the log file. Before quitting SyncEvolution will print a summary of how
147 the local data was modified. This is done with the synccompare utility
148 script described in the Exchanging Data section.
149 When the logdir option is enabled (since v0.9 done by default for new
151 configurations), then the same comparison is also done before the syn‐
152 chronization starts.
153 In case of a severe error the synchronization run is aborted prema‐
155 turely and SyncEvolution will return a non-zero value. Recovery from
156 failed synchronization is done by forcing a full synchronization during
157 the next run, i.e. by sending all items and letting the SyncML server
158 compare against the ones it already knows. This is avoided whenever
159 possible because matching items during a slow synchronization can lead
160 to duplicate entries.
161 After a successful synchronization the server's configuration file is
163 updated so that the next run can be done incrementally. If the config‐
164 uration file has to be recreated e.g. because it was lost, the next run
165 recovers from that by doing a full synchronization. The risk associated
166 with this is that the server might not recognize items that it already
167 has stored previously which then would lead to duplication of items.
168 syncevolution --configure <options for configuration> <config> [<source> ...]
170 Options in the configuration can be modified via the command line.
172 Source properties are changed for all sources unless sources are listed
173 explicitly. Some source properties have to be different for each
174 source, in which case syncevolution must be called multiple times with
175 one source listed in each invocation.
176 syncevolution --remove <config>
178 Deletes the configuration. If the <config> refers to a specific peer,
180 only that peer's configuration is removed. If it refers to a context,
181 that context and all peers inside it are removed.
182 Note that there is no confirmation question. Neither local data refer‐
184 enced by the configuration nor the content of log dirs are deleted.
185 syncevolution --run <options for run> <config> [<source> ...]
187 Options can also be overridden for just the current run, without chang‐
189 ing the configuration. In order to prevent accidentally running a sync
190 session when a configuration change was intended, either --configure or
191 --run must be given explicitly if options are specified on the command
192 line.
193 syncevolution --status <config> [<source> ...]
195 Prints what changes were made locally since the last synchronization.
197 Depends on access to database dumps from the last run, so using the
198 logdir option is recommended.
199 syncevolution --print-servers|--print-configs|--print-peers
201 syncevolution --print-config [--quiet] <config> [main|<source> ...]
202 syncevolution --print-sessions [--quiet] <config>
203 These commands print information about existing configurations. When
205 printing a configuration a short version without comments can be
206 selected with --quiet. When sources are listed, only their configura‐
207 tion is shown. Main instead or in combination with sources lists only
208 the main peer configuration.
209 syncevolution --restore <session directory> --before|--after
211 [--dry-run] <config> <source> ...
212 This restores local data from the backups made before or after a syn‐
214 chronization session. The --print-sessions command can be used to find
215 these backups. The source(s) have to be listed explicitly. There is
216 intentionally no default, because as with --remove there is no confir‐
217 mation question. With --dry-run, the restore is only simulated.
218 The session directory has to be specified explicitly with its path name
220 (absolute or relative to current directory). It does not have to be one
221 of the currently active log directories, as long as it contains the
222 right database dumps for the selected sources.
223 A restore tries to minimize the number of item changes (see section
225 Item Changes and Data Changes). This means that items that are identi‐
226 cal before and after the change will not be transmitted anew to the
227 server during the next synchronization. If the server somehow needs to
228 get a clean copy of all items on the client then, use "--sync
229 refresh-from-client" in the next run.
230 syncevolution --print-items <config> <source>
232 syncevolution [--delimiter <string>] --export <dir>|<file>|- <config> <source> [<luid> ...]
233 syncevolution [--delimiter <string>|none] --import <dir>|<file>|- <config> <source>
234 syncevolution --update <dir> <config> <source>
235 syncevolution [--delimiter <string>|none] --update <file>|- <config> <source> <luid> ...
236 syncevolution --delete-items <config> <source> (<luid> ... | *)
237 Restore depends on the specific format of the automatic backups created
239 by SyncEvolution. Arbitrary access to item data is provided with addi‐
240 tional options. <luid> here is the unique local identifier assigned to
241 each item in the source, transformed so that it contains only alphanu‐
242 meric characters, dash and underscore. A star * in --delete-items
243 selects all items for deletion.
244 <config> and <source> must be given, but they do not have to refer to
246 existing configurations. In that case, the desired backend and must be
247 give via "--source-property type=<backend>", like this:
248 syncevolution --print-items --source-property type=evolution-contacts dummy-config dummy-source
250 The desired backend database can be chosen via "--source-property evo‐
252 lutionsource".
253
255 Here is a full description of all <options> that can be put in front of
256 the server name. Whenever an option accepts multiple values, a question
257 mark can be used to get the corresponding help text and/or a list of
258 valid values.
259 --sync|-s <mode>|?
261 Temporarily synchronize the active sources in that mode. Useful
262 for a refresh-from-server or refresh-from-client sync which
263 clears all data at one end and copies all items from the other.
264 --print-servers|--print-configs|--print-peers
266 Prints the names of all configured peers to stdout. There is no
267 difference between these options, the are just aliases.
268 --print-servers|--print-configs|--print-peers|-p
270 Prints the complete configuration for the selected <config> to
271 stdout, including up-to-date comments for all properties. The
272 format is the normal .ini format with source configurations in
273 different sections introduced with [<source>] lines. Can be com‐
274 bined with --sync-property and --source-property to modify the
275 configuration on-the-fly. When one or more sources are listed
276 after the <config> name on the command line, then only the con‐
277 figs of those sources are printed. main selects the main config‐
278 uration instead of source configurations. Using --quiet sup‐
279 presses the comments for each property. When setting a --tem‐
280 plate, then the reference configuration for that peer is printed
281 instead of an existing configuration.
282 --print-sessions
284 Prints information about previous synchronization sessions for
285 the selected peer or context are printed. This depends on the
286 logdir option. The information includes the log directory name
287 (useful for --restore) and the synchronization report. In combi‐
288 nation with --quiet, only the paths are listed.
289 --configure|-c
291 Modify the configuration files for the selected peer and/or
292 sources. If no such configuration exists, then a new one is
293 created using one of the template configurations (see --template
294 option). When creating a new configuration and listing sources
295 explicitly on the command line, only those sources will be set
296 to active in the new configuration, i.e. syncevolution -c memo‐
297 too addressbook followed by syncevolution memotoo will only syn‐
298 chronize the address book. The other sources are created in a
299 disabled state. When modifying an existing configuration and
300 sources are specified, then the source properties of only those
301 sources are modified.
302 --run|-r
304 To prevent accidental sync runs when a configuration change was
305 intended, but the --configure option was not used, --run must be
306 specified explicitly when sync or source properties are selected
307 on the command line and they are meant to be used during a sync
308 session triggered by the invocation.
309 --migrate
311 In older SyncEvolution releases a different layout of configura‐
312 tion files was used. Using --migrate will automatically migrate
313 to the new layout and rename the <config> into <config>.old to
314 prevent accidental use of the old configuration. WARNING: old
315 SyncEvolution releases cannot use the new configuration!
316 The switch can also be used to migrate a configuration in the
318 current configuration directory: this preserves all property
319 values, discards obsolete properties and sets all comments
320 exactly as if the configuration had been created from scratch.
321 WARNING: custom comments in the configuration are not preserved.
322 --migrate implies --configure and can be combined with modifying
324 properties.
325 --print-items
327 Shows all existing items using one line per item using the for‐
328 mat "<luid>[: <short description>]". Whether the description is
329 available depends on the backend and the kind of data that it
330 stores.
331 --export
333 Writes all items in the source or all items whose <luid> is
334 given into a directory if the --export parameter exists and is a
335 directory. The <luid> of each item is used as file name. Other‐
336 wise it creates a new file under that name and writes the
337 selected items separated by the chosen delimiter string. stdout
338 can be selected with a dash.
339 The default delimiter (two line breaks) matches a blank line. As
341 a special case, it also matches a blank line with DOS line end‐
342 ing (line break, carriage return, line break). This works for
343 vCard 3.0 and iCalendar 2.0, which never contain blank lines.
344 When exporting, the default delimiter will always insert two
346 line breaks regardless whether the items contain DOS line ends.
347 As a special case, the initial newline of a delimiter is skipped
348 if the item already ends in a newline.
349 --import
351 Adds all items found in the directory or input file to the
352 source. When reading from a directory, each file is treated as
353 one item. Otherwise the input is split at the chosen delimiter.
354 "none" as delimiter disables splitting of the input.
355 --update
357 Overwrites the content of existing items. When updating from a
358 directory, the name of each file is taken as its luid. When
359 updating from file or stdin, the number of luids given on the
360 command line must match with the number of items in the input.
361 --delete-items
363 Removes the specified items from the source. Most backends print
364 some progress information about this, but besides that, no fur‐
365 ther output is produced. Trying to remove an item which does not
366 exist typically leads to an ERROR message, but is not reflected
367 in a non-zero result of the command line invocation itself
368 because the situation is not reported as an error by backends
369 (removal of non-existent items is not an error in SyncML). Use a
370 star * instead or in addition to listing individual luids to
371 delete all items.
372 --sync-property|-y <property>=<value>|<property>=?|?
374 Overrides a source-independent configuration property for the
375 current synchronization run or permanently when --configure is
376 used to update the configuration. Can be used multiple times.
377 Specifying an unused property will trigger an error message.
378 When using the configuration layout introduced with 1.0, some of
380 the sync properties are shared between peers, for example the
381 directory where sessions are logged. Permanently changing such a
382 shared property for one peer will automatically update the prop‐
383 erty for all other peers in the same context because the prop‐
384 erty is stored in a shared config file. When printing a config
385 in verbose mode, a summary comment shows which properties are
386 shared in which way.
387 --source-property|-z <property>=<value>|<property>=?|?
389 Same as --sync-property, but applies to the configuration of all
390 active sources. --sync <mode> is a shortcut for --source-prop‐
391 erty sync=<mode>.
392 When combined with --configure, the configuration of all sources
394 is modified. The value is applied to all sources unless sources
395 are listed explicitly on the command line. So if you want to
396 change a source property of just one specific sync source, then
397 use --configure --source-property ... <server> <source>.
398 As with sync properties, some properties are shared between
400 peers, in particular the selection of which local data to syn‐
401 chronize.
402 --template|-l <peer name>|default|?<device>
404 Can be used to select from one of the built-in default configu‐
405 rations for known SyncML peers. Defaults to the <config> name,
406 so --template only has to be specified when creating multiple
407 different configurations for the same peer, or when using a tem‐
408 plate that is named differently than the peer. default is an
409 alias for memotoo and can be used as the starting point for
410 servers which do not have a built-in template.
411 A pseudo-random device ID is generated automatically. Therefore
413 setting the deviceId sync property is only necessary when manu‐
414 ally recreating a configuration or when a more descriptive name
415 is desired.
416 The available templates for different known SyncML servers are
418 listed when using a single question mark instead of template
419 name. When using the ?<device> format, a fuzzy search for a tem‐
420 plate that might be suitable for talking to such a device is
421 done. The matching works best when using <device> = <Manufac‐
422 turer> <Model>. If you don't know the manufacturer, you can just
423 keep it as empty. The output in this mode gives the template
424 name followed by a short description and a rating how well the
425 template matches the device (100% is best).
426 --status|-t
428 The changes made to local data since the last synchronization
429 are shown without starting a new one. This can be used to see in
430 advance whether the local data needs to be synchronized with the
431 server.
432 --quiet|-q
434 Suppresses most of the normal output during a synchronization.
435 The log file still contains all the information.
436 --keyring|-k
438 Save or retrieve passwords from the GNOME keyring when modifying
439 the configuration or running a synchronization. Note that using
440 this option applies to all passwords in a configuration, so set‐
441 ting a single password as follows moves the other passwords into
442 the keyring, if they were not stored there already:
443 --keyring --configure --sync-property proxyPassword=foo
445 When passwords were stored in the keyring, their value is set to
447 a single hyphen ("-") in the configuration. This means that when
448 running a synchronization without the --keyring argument, the
449 password has to be entered interactively. The --print-config
450 output always shows "-" instead of retrieving the password from
451 the keyring.
452 --daemon[=yes/no]
454 By default, the SyncEvolution command line is executed inside
455 the syncevo-dbus-server process. This ensures that synchroniza‐
456 tion sessions started by the command line do not conflict with
457 sessions started via some other means (GUI, automatically). For
458 debugging purposes or very special use cases (running a local
459 sync against a server which executes inside the daemon) it is
460 possible to execute the operation without the daemon (--dae‐
461 mon=no).
462 --help|-h
464 Prints usage information.
465 --version
467 Prints the SyncEvolution version.
468
470 List the known configuration templates:
471 syncevolution --template ?
473 Create a new configuration, using the existing Memotoo template:
475 syncevolution --configure \
477 --sync-property "username=123456" \
478 --sync-property "password=!@#ABcd1234" \
479 memotoo
480 Note that putting passwords into the command line, even for short-lived
482 processes as the one above, is a security risk in shared environments,
483 because the password is visible to everyone on the machine. To avoid
484 this, remove the password from the command above, then add the password
485 to the right config.ini file with a text editor. This command shows
486 the directory containing the file:
487 syncevolution --print-configs
489 Review configuration:
491 syncevolution --print-config memotoo
493 Synchronize all sources:
495 syncevolution memotoo
497 Deactivate all sources:
499 syncevolution --configure \
501 --source-property sync=none \
502 memotoo
503 Activate address book synchronization again, using the --sync shortcut:
505 syncevolution --configure \
507 --sync two-way \
508 memotoo addressbook
509 Change the password for a configuration:
511 syncevolution --configure \
513 --sync-property password=foo \
514 memotoo
515 Set up another configuration for under a different account, using the
517 same default databases as above:
518 syncevolution --configure \
520 --sync-property username=joe \
521 --sync-property password=foo \
522 --template memotoo \
523 memotoo_joe
524 Set up another configuration using the same account, but different
526 local databases (can be used to simulate synchronizing between two
527 clients, see Exchanging Data:
528 syncevolution --configure \
530 --sync-property "username=123456" \
531 --sync-property "password=!@#ABcd1234" \
532 --source-property sync=none \
533 memotoo@other
534 syncevolution --configure \
536 --source-property evolutionsource=<name of other address book> \
537 @other addressbook
538 syncevolution --configure \
540 --source-property sync=two-way \
541 memotoo@other addressbook
542 syncevolution memotoo
544 syncevolution memotoo@other
545 Migrate a configuration from the <= 0.7 format to the current one
547 and/or updates the configuration so that it looks like configurations
548 created anew with the current syncevolution:
549 syncevolution --migrate memotoo
551
553 Exchanging Data
554 SyncEvolution transmits address book entries as vCard 2.1 or 3.0
555 depending on the type chosen in the configuration. Evolution uses 3.0
556 internally, so SyncEvolution converts between the two formats as
557 needed. Calendar items and tasks can be sent and received in iCalendar
558 2.0 as well as vCalendar 1.0, but vCalendar 1.0 should be avoided if
559 possible because it cannot represent all data that Evolution stores.
560 Note The Evolution backends are mentioned as examples; the same
562 applies to other data sources.
563 How the server stores the items depends on its implementation and con‐
565 figuration. To check which data is preserved, one can use this proce‐
566 dure (described for contacts, but works the same way for calendars and
567 tasks):
568 1. synchronize the address book with the server
570 2. create a new address book in Evolution and view it in Evolution once
572 (the second step is necessary in at least Evolution 2.0.4 to make
573 the new address book usable in SyncEvolution)
574 3. add a configuration for that second address book and the same URI on
576 the SyncML server, see EXAMPLES above
577 4. synchronize again, this time using the other data source
579 Now one can either compare the address books in Evolution or do that
581 automatically, described here for contacts:
582 · save the complete address books: mark all entries, save as vCard
584 · invoke synccompare with two file names as arguments and it will nor‐
586 malize and compare them automatically
587 Normalizing is necessary because the order of cards and their proper‐
589 ties as well as other minor formatting aspects may be different. The
590 output comes from a side-by-side comparison, but is augmented by the
591 script so that the context of each change is always the complete item
592 that was modified. Lines or items following a ">" on the right side
593 were added, those on the left side followed by a "<" were removed, and
594 those with a "|" between text on the left and right side were modified.
595 The automatic unit testing (see HACKING) contains a testItems test
597 which verifies the copying of special entries using the same method.
598 Modifying one of the address books or even both at the same time and
600 then synchronizing back and forth can be used to verify that SyncEvolu‐
601 tion works as expected. If you do not trust SyncEvolution or the
602 server, then it is prudent to run these checks with a copy of the orig‐
603 inal address book. Make a backup of the .evolution/addressbook direc‐
604 tory.
605 Item Changes and Data Changes
607 SyncML clients and servers consider each entry in a database as one
608 item. Items can be added, removed or updated. This is the item change
609 information that client and server exchange during a normal, incremen‐
610 tal synchronization.
611 If an item is saved, removed locally, and reimported, then this is usu‐
613 ally reported to a peer as "one item removed, one added" because the
614 information available to SyncEvolution is not sufficient to determine
615 that this is in fact the same item. One exception are iCalendar 2.0
616 items with their globally unique ID: the modification above will be
617 reported to the server as "one item updated".
618 That is better, but still not quite correct because the content of the
620 item has not changed, only the meta information about it which is used
621 to detect changes. This cannot be avoided without creating additional
622 overhead for normal synchronizations.
623 SyncEvolution reports item changes (the number of added, removed and
625 updated items) as well as data changes. These data changes are calcu‐
626 lated by comparing database dumps using the synccompare tool. Because
627 this data comparison ignores information about which data belongs to
628 which item, it is able to detect that re-adding an item that was
629 removed earlier does not change the data, in contrast to the item
630 changes. On the other hand, removing one item and adding a different
631 one may look like updating just one item.
632 Automatic Backups and Logging
634 To support recovery from a synchronization which damaged the local data
635 or modified it in an unexpected way, SyncEvolution can create the fol‐
636 lowing files during a synchronization:
637 · a dump of the data in a format which can be restored by SyncEvolu‐
639 tion, usually a single file per item containing in a standard text
640 format (VCARD/VCALENDAR)
641 · a full log file with debug information
643 · another dump of the data after the synchronization for automatic com‐
645 parison of the before/after state with synccompare
646 If the server configuration option "logdir" is set, then a new direc‐
648 tory will be created for each synchronization in that directory, using
649 the format <peer>-<yyyy>-<mm>-<dd>-<hh>-<mm>[-<seq>] with the various
650 fields filled in with the time when the synchronization started. The
651 sequence suffix will only be used when necessary to make the name
652 unique. By default, SyncEvolution will never delete any data in that
653 log directory unless explicitly asked to keep only a limited number of
654 previous log directories.
655 This is done by setting the "maxlogdirs" limit to something different
657 than the empty string and 0. If a limit is set, then SyncEvolution will
658 only keep that many log directories and start removing the "less inter‐
659 esting" ones when it reaches the limit. Less interesting are those
660 where no data changed and no error occurred.
661 To avoid writing any additional log file or database dumps during a
663 synchronization, the "logdir" can be set to "none". To reduce the ver‐
664 bosity of the log, set "loglevel". If not set or 0, then the verbosity
665 is set to 3 = DEBUG when writing to a log file and 2 = INFO when writ‐
666 ing to the console directly. To debug issues involving data conversion,
667 level 4 also dumps the content of items into the log.
668
670 The following environment variables control where SyncEvolution finds
671 files and other aspects of its operations.
672 http_proxy
674 Overrides the proxy settings temporarily. Setting it to an empty
675 value disables the normal proxy settings.
676 HOME/XDG_CACHE_HOME/XDG_CONFIG_HOME
678 SyncEvolution follows the XDG desktop standard for its files. By
679 default, $HOME/.config/syncevolution is the location for config‐
680 uration files. $HOME/.cache/syncevolution holds session direc‐
681 tories with log files and database dumps.
682 SYNCEVOLUTION_DEBUG
684 Setting this to any value disables the filtering of stdout and
685 stderr that SyncEvolution employs to keep noise from system
686 libraries out of the command line output.
687 SYNCEVOLUTION_GNUTLS_DEBUG
689 Enables additional debugging output when using the libsoup HTTP
690 transport library.
691 SYNCEVOLUTION_BACKEND_DIR
693 Overrides the default path to plugins, normally
694 /usr/lib/syncevolution/backends.
695 SYNCEVOLUTION_TEMPLATE_DIR
697 Overrides the default path to template files, normally
698 /usr/share/syncevolution/templates.
699 SYNCEVOLUTION_XML_CONFIG_DIR
701 Overrides the default path to the Synthesis XML configuration
702 files, normally /usr/share/syncevolution/xml. These files are
703 merged into one configuration each time the Synthesis SyncML
704 engine is started as part of a sync session.
705 Note that in addition to this directory, SyncEvolution also
707 always searches for configuration files inside $HOME/.con‐
708 fig/syncevolution-xml. Files with the same relative path and
709 name as in /usr/share/syncevolution/xml override those files,
710 others extend the final configuration.
711
713 See known issues and the support web page for more information.
714
716 http://syncevolution.org
717
719 Main developer
720 Patrick Ohly <patrick.ohly@intel.com>, http://www.estamos.de
721 Contributors
723 http://syncevolution.org/about/contributors
724 To contact the project publicly (preferred)
726 syncevolution@syncevolution.org
727 Intel-internal team mailing list (confidential)
729 syncevolution@lists.intel.com
7301.1.1 2011-04-28 SYNCEVOLUTION(1)