Syncevolution should use unambiguous identifications about which store is which

[AlainKnaff]

After encountering persistent errors during synchronization, I'm intending to overwrite the calendar on my phone with the calendar from the server, i.e. lose any changes that I might have done "locally" on the phone.

However, the --sync options seems to have a confusing way to identify each side:

--sync|-s <mode>|?
  Temporarily synchronize the active datastores in that mode. Useful
  for a `refresh-from-local` or `refresh-from-remote` sync which
  clears all data at one end and copies all items from the other.

  **Warning:** `local` is the data accessed via the sync config
  directly and `remote` is the data on the peer, regardless
  where the data is actually stored physically.

This indeed seems to hint that local might not actually be the phone (where I run the command) but the server. _Might_, because it might also be the other way round. And there seems to be no obvious way of display the URL of the peer, and/or the URL of the "sync config".

1.
# lsb_release -rd
Description: Ubuntu 15.04
Release: 15.04

2.
# apt-cache policy syncevolution
syncevolution:
  Installed: 1.5.1+15.04.20160706-0ubuntu1
  Candidate: 1.5.1+15.04.20160706-0ubuntu1
  Version table:
 *** 1.5.1+15.04.20160706-0ubuntu1 0
       1001 http://ppa.launchpad.net/ci-train-ppa-service/stable-snapshot/ubuntu/ vivid/main armhf Packages
        100 /var/lib/dpkg/status
     1.5-0ubuntu4 0
        500 http://ports.ubuntu.com/ubuntu-ports/ vivid/universe armhf Packages

3. What I expect to happen
  a. sync-modes should be named after "sync config" and "peer", if these are the concepts used internally by sync-evolution rather than the potentially confusing "local" and "remote"

--sync|-s <mode>|?
  Temporarily synchronize the active datastores in that mode. Useful
  for a `refresh-from-sync-config` or `refresh-from-peer` sync which
  clears all data at one end and copies all items from the other.

  To tell which data store is which, use the --print-sync-config-url and --print-peer-url commands.
  The local calendar's URL would then be called (for example) evolution:aev and the remote URL https://<email address hidden>/calendar

4. What happened instead
A vague warning not to get local and remote mixed up, but without any clear guideline to tell which is which. Even grepping the .config files doesn't help, as the server's URL shows in a file under "sources" rather than "peers" or "sync-configs"

When talking about the direction of a copy, there should be no doubt nor ambiguity, or else someone *will* overwrite a good copy with a bad.

[AlainKnaff (kubuntu-misc)]

Epilogue: Eventually I took my courage in my 2 hands, and did a syncevolution -s refresh-from-remote AEV aev

It did indeed do the thing that I would intuitively expect, i.e. refresh the store on the phone from the server.

However, please be careful as there is more than one way to set up syncevolution, in some situations it *might* indeed be backwards...