Switching between WebDAV and Bonjour
 

Usually I do a local bonjour sync, but occasionally I'd like to sync to a WebDAV server. However, it looks like OF does not remember the WebDAV once I switched back to Bonjour, and then once I go back to Bonjour it tells me right away my iPhone database is incompatible and I have to either "keep device" or "keep sync." First of all, the choices are very confusingly named -- should be "this" or "remote". Second, this is inconvenient in general.

Can we keep both options and sync at a flick of a button? Ideally the switch would be close, even on the toolbar. "Local sync" and "remote sync."

Unfortunately, it's not just a matter of picking a different network protocol for the sync. There's a shared database that each client syncs its own database with, and when you switch from MobileMe to Bonjour sync, you are pointing at a different database, which hasn't been updated while you've been syncing with the other method. That's why you get the warning about incompatible databases, because they are! You don't sync directly with your other client(s), but with that central database, though it doesn't necessarily appear that way if you don't look closely enough.

Previous versions used the local/remote terminology, and there was enough confusion that the current terminology was adopted.

Then it's a limitation. Repos should be like git, any to any. It should ask me, whether I want to refresh the Bonjour'ed one from my iPhone now... Wait, it does? "Keep device" will refresh the Mac?

I haven't used git, so I won't try to answer in git terms. Think more like a RCS repository, with no fancy distributed system. Each one of your clients checks out a tree, makes changes, and commits the changes back to the central repository. You don't get the changes made by another client until you do a sync. When you switch from MobileMe to Bonjour, you are taking your tree (which has no version history) and establishing a brand new repository, but you don't get to have any history of how you got to that point.

"Keep device" takes what you have and makes a new sync database from it. When the Mac (or another iPhone/iPod) goes to sync, they will detect that the new sync database is no longer compatible with theirs and ask the same question. Assuming you intentionally replaced the sync database, you would tell them to take the sync database.

If you have some sort of cock-up where devices get out of sync and you have changes on more than one that you need to save, you can use this same behavior to your advantage. Go to the first device, and tell it to replace the sync database ("keep device"). Go to the next device, and change its configuration to sync to a different path (if using MobileMe/WebDAV -- it's a bit more complicated to describe what to do for the Bonjour case, so I'm going to be lazy and not do so as you don't actually have a problem). Then tell it to sync, which will write a copy of its local database to that new spot. Repeat for any other clients, using different paths for each. Now you can go back to the devices which saved their changes to new spots, configure them to sync to the usual place and have them do so, keeping the sync database. Finally, copy those extra sync databases to the same Mac, double-click each one, and drag and drop or otherwise duplicate any changes that you need to rescue into the main database window.

Yes, it's a limitation, but it's far from obvious to me that removing the limitation is worth the effort, considering all the other features the developers and the users want added. People who aren't going to use that functionality (probably the vast majority) will squawk if any new bugs are introduced into their sync functionality, and the people who want some other feature which doesn't get done because the needed engineering resources went to this won't be happy either. Impossible for us to know whether the forum traffic is proportional to the requests made to the support ninjas via Help->Send Feedback and email to [email]omnifocus@omnigroup.com[/email] (which are the feature requests that actually matter), but number of people I see requesting this feature is small compared to a lot of other features of seemingly comparable difficulty. If it's really important to you, send in your feature request as above...