TreeShare has the potential to be the most popular enhancement that has ever been made to RM. But TreeShare has its problems
One of the most significant TreeShare problems is the absence of any kind of automated upload or download after the the initial syncing between RM and ancestry. I know from personal experience that I can spend one hour updating RM and then have to spend two or three hours approving those same updates to be moved from RM to ancestry. That is simply not acceptable.
When TreeShare was first announced, the absence of any kind of automated upload or download was presented instead as an advantage as compared to an automated sync process. The reason stated was that a manual sync process would assure a much higher level of data integrity than would an automated sync process. Even the beta testers were strongly supportive of this point of view. And some of them had horror stories to tell about sync between FTM and ancestry gone awry.
It has also been stated that TreeShare is not designed to be a sync process. That's one of the reasons it's called TreeShare rather than TreeSync. So let me try to imagine a safe way that TreeShare could be automated.
But before I do, let me go back into the history of RM just a little bit. Once upon a time, RM introduced a new feature called ShareMerge. Here's the description of ShareMerge, taken directly from the RM screen.
If you send a GEDCOM from your RootsMagic database to another RootsMagic user, they can import and make changes to that file, and return it to you. You can import that modified GEDCOM into your database and use this option to automatically merge the two copies of the database back together.
This makes ShareMerge sound pretty good. But in a very fundamental way, ShareMerge doesn't really work. The problem is that even though the matching and merging of people is automatic, the merging of facts and sources isn't. So there is still a great deal of manual work that has to be done to complete the ShareMerge process. What's really needed with ShareMerge is that the individuals in the the newly imported GEDCOM replace the corresponding people that are already in your database.
If this sounds similar to some of the problems with TreeShare, it's because it is. For example, suppose that you create an ancestry tree by using the TreeShare process to copy all of your RM database to ancestry. Furthermore, suppose you subsequently make all your updates in RM. Then you don't need a "sync" operation or a "share" operation. All you need is for all your updates in RM to replace or to be added to what is in ancestry. The process can be fully automated and is completely safe with no approvals whatsoever.
The exact same thing is true in the other direction. You can create your RM database from an ancestry tree and make all subsequent updates in ancestry. Again, all you need is a replace operation. The process can be fully automated and can be completely safe.
I could anticipate that a fully automated and bi-directional sync between RM and ancestry could be extremely difficult to accomplish and might not be very safe. So as an interim measure, I would like to re-imagine what the product should look like. I would like to suggest an automated mode of operation that is one directional only and that replaces rather than syncs. The existing bi-directional mode of operation with a manual approval process could remain, but I think many, many RM users could benefit from a one-directional replace mode of operation - and the one-directional replace mode of operation would be very safe.