Jump to content


Photo

Re-Imagining TreeShare


  • Please log in to reply
9 replies to this topic

#1 c24m48

c24m48

    Advanced Member

  • Members
  • PipPipPip
  • 2612 posts

Posted 13 September 2017 - 11:15 AM

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.

 

Jerry

 



#2 RRJ

RRJ

    New Member

  • Members
  • Pip
  • 1 posts

Posted 14 September 2017 - 09:37 AM

I for one would greatly benefit from such a scheme.

 

Richard



#3 keithcstone

keithcstone

    Advanced Member

  • Members
  • PipPipPip
  • 46 posts

Posted 14 September 2017 - 01:59 PM

I mentioned some ideas for this very thing here:

 

            #19            



#4 c24m48

c24m48

    Advanced Member

  • Members
  • PipPipPip
  • 2612 posts

Posted 14 September 2017 - 03:38 PM

I mentioned some ideas for this very thing here:

 

            #19            

 

There are some similarities, but as long as processing is in one direction only, I hadn't imagined the user having to deal with individual events or individual media or individual people. Dealing with things at that level of granularity is part of the problem.

  • In the chosen direction, I imagine people newly added to this side to be added to the other side without manual approval just as would happen in an initial load.
  • In the chosen direction, I imagine people newly deleted from this side to be deleted from the other side without manual approval.
  • In the chosen direct, I imagine people newly updated on this side to be updated on the other side without manual approval. When it updated newly updated people other side, it would make the person on the other side look just like the person on this side, as if the updated person had been deleted and then added to the other side - except that family relationships would be fully maintained as a part of the update operation. I'm just trying to describe the result of the update operation, not saying that it literally would be accomplished by a delete of the person on the other side followed by an add of the person on the other side.

Jerry



#5 keithcstone

keithcstone

    Advanced Member

  • Members
  • PipPipPip
  • 46 posts

Posted 18 September 2017 - 03:32 PM

I guess my description wasn't clear enough, as I wasn't looking at individual people or events as much as groups of them. My intent it so be able to select an update and direction for a class of changes (i.e. new people on the RootsMagic side) and push them all up in one click and approve. If you've updated 1000 place names locally you'd know that, and approve all those changes to go upstream with a few clicks not 2000.



#6 c24m48

c24m48

    Advanced Member

  • Members
  • PipPipPip
  • 2612 posts

Posted 18 September 2017 - 04:53 PM

We are probably closer to agreement than it might sound. In my one directional mode, all changes would be approved with one click. It wouldn't matter whether the changes were adds, deletes, or updates. And it wouldn't matter if the changes were whole people, or just facts, notes, sources, or media. I would still have some reservations about a one click approval mode for bi-directional changes.

 

You also mentioned "groups of people". I think by "groups of people" you mean everybody who has changed - or maybe everybody who has had a particular kind of change such as a bulk place name change. I would also like to have a "groups of people" mode in the direction from RM to ancestry, literally where the only people shared from RM to ancestry would be from an RM named group. Adding someone to the named group would cause the person to be added to ancestry and deleting the person from the named group would cause the person to be deleted from ancestry. The person would still be there in RM in any case unless you actually deleted them from RM. This would be a huge benefit and I think would work fine in a uni-directional mode going only from RM to ancestry. It's not real clear to me that it could work in the other direction because the "groups" would have to be on the ancestry side of the house and ancestry doesn't have groups.

 

Jerry



#7 keithcstone

keithcstone

    Advanced Member

  • Members
  • PipPipPip
  • 46 posts

Posted 18 September 2017 - 05:51 PM

You are correct that I mean a "group" is everyone has been updated, although I like your idea of being able to designate another group (for upstream) that would be a subset of those updated.



#8 genealogy4primm@earthlink.

genealogy4primm@earthlink.

    Advanced Member

  • Members
  • PipPipPip
  • 67 posts

Posted 18 September 2017 - 06:26 PM

If Groups had the "Mark group" selection choice of  "Changes since Last edited date X" (and better if a nested selection within/of existing group) would make this feasible.



#9 c24m48

c24m48

    Advanced Member

  • Members
  • PipPipPip
  • 2612 posts

Posted 19 September 2017 - 12:28 PM

If Groups had the "Mark group" selection choice of  "Changes since Last edited date X" (and better if a nested selection within/of existing group) would make this feasible.

 

I'm not sure if we are talking about the same thing or not. My current database has about 60,000 people. What if I only wanted about 2,000 of them to be in my tree on ancestry. Suppose that I wanted to do all changes in RM and only "sync" in one direction ("syncing" by replacing from RM to ancestry). I could make a smaller RM database to link to ancestry, but that way lies madness. So I would like to continue to have just my one RM database with 60,000 people. But when I first create my ancestry tree from RM, I would like to tell RM only to upload from a particular Named Group which I would already have prepared - said Named Group containing about 2,000 people. All subsequent operations between RM and ancestry would operate only on this Named Group. From ancestry's point of view, it would be as if this Named Group were the whole database. No additional support would be required on ancestry's side of the house. ancestry wouldn't know and wouldn't care that anything out of the ordinary was going on.

 

Jerry



#10 beesmyer

beesmyer

    Member

  • Members
  • PipPip
  • 6 posts

Posted 22 September 2017 - 11:14 AM

RM desperately needs an auto sync feature one way or another. Let the user decide their own work flow.