Jump to content


Photo

Re-Imagining TreeShare


  • Please log in to reply
14 replies to this topic

#1 Jerry Bryan

Jerry Bryan

    Advanced Member

  • Members
  • PipPipPip
  • 3409 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
  • 3 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
  • 121 posts

Posted 14 September 2017 - 01:59 PM

I mentioned some ideas for this very thing here:

 

            #19            



#4 Jerry Bryan

Jerry Bryan

    Advanced Member

  • Members
  • PipPipPip
  • 3409 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
  • 121 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 Jerry Bryan

Jerry Bryan

    Advanced Member

  • Members
  • PipPipPip
  • 3409 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
  • 121 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
  • 70 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 Jerry Bryan

Jerry Bryan

    Advanced Member

  • Members
  • PipPipPip
  • 3409 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.

#11 gerwally

gerwally

    Advanced Member

  • Members
  • PipPipPip
  • 103 posts

Posted 24 September 2017 - 11:00 PM

I have decided to periodically delete my tree on Ancestry and upload a new tree from RM to Ancestry with the updated changes in the RM database.   I uploaded a tree to Ancestry in the past via GEDCOM but now can upload it to Ancestry via TreeShare and have media upload also but do not want to take the time to make individual changes to sync between the two.  I never kept a tree on Ancestry whereby I attached sources such as censuses directly to it so synciing is not an issue for me.



#12 bradleydell

bradleydell

    New Member

  • Members
  • Pip
  • 1 posts

Posted 20 November 2017 - 11:23 PM

I like this idea, Jerry. Most people have a working tree, whether it's Rm or Ancestry, mines Ancestry. The one-directional replace mode would fit how I would use my trees. You just have to make that decision, at the beginning, which way the info is going to go... 



#13 pbooth99

pbooth99

    Advanced Member

  • Members
  • PipPipPip
  • 39 posts

Posted 12 June 2019 - 11:55 PM

I like this idea, Jerry. Most people have a working tree, whether it's Rm or Ancestry, mines Ancestry. The one-directional replace mode would fit how I would use my trees. You just have to make that decision, at the beginning, which way the info is going to go... 

 

For me, this is the root of the challenge. If I want to research a new or unconnected branch of my tree,

I might create a special purpose RM DB that is initially seeded with three generations of people.

I then have two very powerful ways to quickly increase the size of that tree:

  1. share the tree with ancestry and use ancestry hints to quickly add connections and facts
  2. share the tree with family search, possibly importing a person and their ancestors or descendants

Both are viable but in one case I end up with many changes in RM that I want to export to ancestry,

in the other I end up with many changes in Ancestry that I want to export to RM. If I do enough work in

one direction only I will reach a tipping point where it seems more time-efficient to disconnect from ancestry

and generate a new ancestry tree from my RM database - or disconnect and download the ancestry tree

into a new RM database. Thats part of why I have 500 ancestry trees! 

 

It's not a great long term process for doing research. What I'd love to have, in its place, would be

some visibility at different levels of detail, between different versions of a database - something akin to git -

but not diffs of a gedcom or even worse an XML file.

 

Sorry that this is more of a whine than a concrete suggestion. Theres an itch here that needs to be scratched, 

but its a hard problem. Certainly more automated ways to perform aggregate operations could help us.

 

Peter

 

  1.  


#14 Jerry Bryan

Jerry Bryan

    Advanced Member

  • Members
  • PipPipPip
  • 3409 posts

Posted 13 June 2019 - 06:32 AM

It's not a great long term process for doing research. What I'd love to have, in its place, would be

some visibility at different levels of detail, between different versions of a database - something akin to git -

but not diffs of a gedcom or even worse an XML file.

 

 

This is off the main topic of the thread, but the need for a "diffs" kind of function is a pretty serious need in RM. I was excited when RM first introduced the File>Compare ability. But my experience is that it is nowhere as useful as I wish it were. Indeed, the first thing I did to test it was to make an exact copy of my database and compare the exact copy to the original. The simple country boy in me expected a quick run which said there were no differences between the databases. But the run was slow, and it identified lots of differences between the databases.

 

The problem seems to be that RM File>Compare doesn't seem to really do a compare. RM already has logic to search for duplicates in one database, and what File>Compare seems to do is to extend this logic across two databases. Suppose for example you have two men named John Doe in your database, one born in 1809 and the other born in 1810. These might be different men, or they might be the same man entered into your database twice with two different birth dates. The File>Compare process seems to do a search for duplicates and to extend the search for duplicates across both databases being compared. So it matches up each of the two John Does in the original database with each of the John Does in the copy - four matches in all - and thereby identifies potential differences in the databases when no differences exist. I have thought about trying to write my own "diffs" program for RM databases, but it is a hard problem.

 

Jerry 



#15 Kamolga

Kamolga

    Advanced Member

  • Members
  • PipPipPip
  • 40 posts

Posted 20 June 2019 - 01:41 PM

 

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.

I feel relief, I thought I did something wrong. I basically stopped the approving process to keep working in RM (I have thousands to update now -> I will export a gedcom and download it in familysearch and Ancestry when I will feel the need), approving is way too much work (and complete loss of time, I don't even need to read, just want all validated). 

This is what I would love: a website (can be MyHeritage, Ancestry, FamilySearch or Rootsmagic Website, it does not matter), preferably with an easy tree navigation that does not need time for people to get into it (MyHeritage or Ancestry are fine), where my account would be an online version of my RM tree. No step on my side. One way live synchronisation.

 

I have only two reasons to share my work online: 

1. Help people: if I could share my work, especially sources, with other RM users, that would be great.

2. Get my family to update their tree, facts, photos, etc. and that is the only approval I agree to do (accept or reject their updates). I do not even mind doing the approved import manually to RM to overwrite them. Icing on the cake: Facebook account to invite, connect and update online.


Rootsmagic 7.5.9.0 with a lot of SQL queries (SQLiteSpy) and a bit of Family Historian 6.2 (tree view and map)