On Tue, 2011-10-18 at 08:35 +0200, Patrick Ohly wrote:
The first paragraphs of the USAGE section are meant to explain the
SyncEvolution specific terms. For example, "A peer is either a SyncML
server (the traditional usage of SyncEvolution) or a client (the new
feature in 1.0)".
Would it be easier to find this when highlighting the new terms or using
a definition list?
I also need to check whether all terms are explained well enough.
> And I didn't quite get the relation between configuration files and the
> "syncevolution --configure" statement. Can I do my changes either way? Can
I
> create a configuration file for a specific source/database? And I missed some
> more examples and a list of options/properties.
All of these are fair points. Let me try to answer with a revised README
sometime this week.
Attached the result as plain text, man page and HTML. Code changes were
made against master in the "documentation" branch; the difference
compared to 1.2 is minor (--print-databases is new on the master
branch). My goal is to back-port to the 1.2 branch.
Stephan, does it make more sense now? It would be very useful to go
through this carefully and report all parts which seem odd or are
inconsistent. For someone who has written the whole thing it is
sometimes hard to spot those.
From the commit:
documentation: added glossary and command line conventions sections, improved listing
of properties
The README.rst now introduces some terms in a glossary directly after
the synopsis. The way how config, sources and properties are used on
the command line are also defined first in their own section, instead
of introducing that further down as part of the options.
The output of "--sync/source-property ?" was changed:
- now it includes information about aliases, default values
and sharing state (useful by itself)
- follows reStructured Text format and thus can be embedded
directly inside the README.rst
--
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.