An Org entry can store much more information than an iCalendar entry, so there is no one-to-one correspondence between the two formats which makes syncing a bit difficult.
This package uses the org-icalendar package to do the export to the
iCalendar format (.ics files). By default, it uses the title of the
Org entry as SUMMARY and puts the entry’s body into DESCRIPTION,
snipping stuff like properties and timestamps (you can override that
with properties of the same name, but IMO it makes stuff just more
complicated). The variable org-icalendar-include-body
denotes how many characters from the body should be included as
DESCRIPTION (by default all characters are included).
If you create a new iCalendar entry in your calendar, you’ll get an
Org entry with SUMMARY as heading, DESCRIPTION as body and the
timestamp. However, if you change an existing entry in the calendar,
things get more complicated and the variable
org-caldav-sync-changes-to-org comes into play. Its default is the
symbol "title-and-timestamp", which means that only the entry’s
heading is synced (with SUMMARY) and the timestamp gets updated, but
not the entry’s body with DESCRIPTION. The simple reason is that
you might loose data, since DESCRIPTION is rather limited in what it
can store. Still, you can set the variable to the symbol "all", which
will completely replace an existing Org entry with the entry that
gets generated from the calendar’s event. You can also limit syncing
to heading and/or timestamp only.
To be extra safe, org-caldav will by default backup entries it
changes. See the variable org-caldav-backup-file for details.
A special case are sexp entries like
%%(diary-anniversary 2 2 1969) Foo's birthday * Regular meeting <%%(diary-float t 4 2)>
As you can see, they can appear in two different ways: plain by themselves, or inside an Org entry. If they are inside an Org entry, there’s a good chance they will be exported (see below) and have an ID property, so they can be found by org-caldav. We can sync the title, but syncing the timestamp with the s-expression is just infeasible, so this will generate a sync error (which are not critical; you’ll just see them at the end of the sync, just so that you’re aware that some stuff wasn’t synced properly).
However, sexp-entries are insanely flexible, and there are limits as to what the icalendar exporter will handle. For example, this here
** Regular event <%%(memq (calendar-day-of-week date) '(1 3 5))>
will not be exported at all.
If the sexp entry is not inside an Org entry but stands by itself,
they still will be exported, but they won’t get an ID (since IDs are
properties linked to Org entries). In practice, that means that you
can delete and change them inside Org and this will be synced, but if
you change them in the calendar, this will not get synced
back. Org-caldav just cannot find those entries, so this will generate
a one-time sync error instead (again: those are not critical, just
FYI). If you don’t want those entries to be exported at all, just set
org-icalendar-include-sexps to nil.