Synchronizing Your Tree With Ancestry to Exploit Hints

Introduction

This article describes a process that enables ƒh users to maintain a synchronized copy of their tree on Ancestry in order to exploit its hint system.

If you want to copy your tree to Ancestry simply for public visibility or for convenient searching of their records, the best option is to periodically export a GEDCOM file and upload this directly.  The Export GEDCOM File plugin is ideal for this purpose.

However, there are additional challenges if you want to exploit Ancestry hints, as each new upload is regarded as a new tree.  This resets hint generation, losing the record of which have already been reviewed.  While updating the Ancestry tree manually is possible for relatively small trees with infrequent changes, this is impractical for larger trees that change frequently.

Automatic synchronisation with Ancestry is not available in ƒh, so the only option available to us is to use an alternative application as an intermediate, and upload from there.  RootsMagic is the recommended product, with the optimum combination of compatibility with ƒh, ease of use, and price point in the market.

Process Overview

Both the initial copying of data from ƒh to Ancestry and subsequent updates follow the same sequence of steps

  1. Exporting a GEDCOM file from ƒh
  2. Importing that file to RootsMagic
  3. Updating the RootsMagic tree with the new information
  4. Uploading changes to Ancestry

Each of those steps is described in more detail below.

Export from Family Historian

In order to facilitate updating database copies, it is essential that each export from ƒh is configured identically, with same set of facts and same criteria for protecting living people.  This is not always easy to achieve with current general purpose export options (either inbuilt or via a plugin), as these are designed to be as flexible as possible, with multiple configuration options.

More consistent results can be obtained by using the “RootsMagic GEDCOM Export for Ancestry” plugin, which exports only basic date and place information for a subset of key events, such as birth, baptism, marriage, census, death, burial, probate, occupation, etc.  All notes, media, and sources are excluded from the export automatically, as is all reference to both living people and any other person marked as Private in your ƒh tree.

The latest version of the plugin (V1.01, 15 Jan 2021) can be downloaded from the FHUG Forum here.

An earlier version of the export script was written in Python (discussed here).  Output from this is fully compatible with that of the plugin (provided that the same set of facts are defined, of course), and if you are currently using it, there is no reason to change.  However, new users should use the plugin, as it is does not require any additional software or configuration of the script file.

More detailed discussion can be found in this Forum thread and links therein, but this KB page is recommended as the most appropriate overview for new users.

Initial Import into RootsMagic and Link to Ancestry

Detailed instructions are given in the RootsMagic help, but this summary describes the key steps.

From the RootsMagic main screen, select File > Import > GEDCOM (Other programs) and select the file created above.  In response to the prompt, select “Create a New Database” and save to a suitable location.  Fill in other options (web hints, surname display, etc) according to your personal preferences.  This will become your master database copy for subsequent updating and synchronisation with Ancestry.

Select “Internet > TreeShare for Ancestry” from either the main program menu or the   toolbar button, and sign in to your Ancestry account (or create an account if you do not have one already).

Select “Upload to new Ancestry Tree”, and give the new tree a suitable name and description.   Select whether the tree is public or private according to your preferences (it makes no difference to the upload and syncing process, or to hint generation).  All other selections for optional content should be cleared, as the upload is just a bare tree without media or sources.

You now have a tree on Ancestry. Tree hints can be reviewed on the Ancestry website, in their IOS/Android apps, or within RootsMagic.  There is no significant functional difference between these, so it is purely personal preference.

Subsequent Updates

Only one RootsMagic file can be linked to a given Ancestry tree. This means that it is not possible to simply repeat this process after making changes to your tree in ƒh, and overwrite the old RootsMagic tree with a new import.  It is necessary to create a new updated tree, compare that with the master copy, and copy across changes as appropriate.

Export from Family Historian

Re-run the “RootsMagic GEDCOM Export for Ancestry” plugin to generate an updated copy of your database. In addition, select “List Individuals” from the plugin menu, then the YourDatabaseName.LST log file in your RootsMagic folder to generate an ordered list of individuals changed since the last import to RootsMagic.  This will serve as a crib sheet of names to review in the subsequent steps, so you may wish to print it for reference. Note that if you have updated something that is not exported to RootsMagic and Ancestry (e.g., adding a new source to a fact without changing the fact itself), the individual concerned will still appear on this list. It will be readily apparent when comparing records in RootsMagic that no action is required.

Comparison of Individual Records in RootsMagic

The recommended method for updating RootsMagic is to import the updated GEDCOM file as a new database. Once imported, close this file, and load your master database.  Select File > Compare files… to load the update file just created.  This opens a “Compare Files” window, where each individual is compared with the corresponding entry in the comparison database, displayed as one column for each file and a “% Match” parameter.  The display can be ordered by any column by clicking on the appropriate heading.

Unfortunately, the %Match may indicate less than 100% match between identical records (although it is clear from the detailed display that nothing has changed).  This is where you will use the crib sheet generated above, so you can order the display by surname and quickly locate the corresponding entry without having to step through false positives.

New individuals added to Family Historian

These will be listed in the comparison file (blue background), but not in the master file (green background).  Click on the “Copy to other file” button to import the individual to your master database.  This only imports the person, not their family relationships, so once you have imported all the new individuals, it is recommended to close the Compare Files window, and build the new family relationships in your master file.  This is usually just a simple case of adding existing individuals as new children or spouses, which is very similar to the corresponding process in ƒh.  When adding a new spouse, it is recommended to also create the marriage event now (if you know that there is one), and either enter the real date and place details or a dummy placeholder that is updated later.  This has proven to be more reliable than trying to add the marriage event during file comparison, as this can produce unpredictable results.

Individuals deleted from Family Historian

Individuals deleted in ƒh will show up as present in your master database but not in the comparison one.  There is no “delete record” option in the Compare Files window, so you should close the window and delete them manually from your RootsMagic master database.

Misidentification

Occasionally, RootsMagic will fail to spot that two entries relate to the same person, and show each one as missing from the other database.  This is most likely to happen if a lot of changes have been made, or at the other extreme, there is relatively little information on which to make the comparison.

The best way of dealing with this is to copy the missing individual into the master database, close the Compare Files window, and use the RootsMagic Tools > Merge > Manual Merge… option (or menu bar button) to merge the new record into the old.

Updating the master database

Once all new and deleted individuals have been processed and any mismatches corrected, you will have the same number of entries in the two columns in the Compare Files window.  It is then a simple matter of working through the list of people generated in the plugin and updating the master file with information from the comparison file.

Most commonly, this involves either updating a fact in the master file, or creating a new one.  If you need to delete a fact from the master file, click on the Edit person button to delete the appropriate fact from the individual’s record.

Updating Ancestry

It is good practice to use the “Tools > Set Living…” menu within RootsMagic to ensure that the “living” flag is cleared from all entries in your database prior to syncing with Ancestry.  Without this step, Ancestry can erroneously mark people without a firm death date as living, even if they are the parent of somebody who died centuries ago.

The final step of uploading your RootsMagic changes to Ancestry is relatively straight forward.  Select “TreeShare for Ancestry…” from the Tools menu (or click on the toolbar button), and log on to your Ancestry account if required (there is a convenient “remember me” option to bypass this step).  From there, simply work through your list of names again and follow the menu prompts to update, add, or delete individuals and facts as necessary.

This Ancestry synchronisation is generally more reliable and user-friendly than the RootsMagic file comparison.  When adding new individuals, family relationships are also copied automatically.  Matching individuals is also very reliable, and probably uses the RootsMagic _UID tag (see below) for unambiguous identification.

Future Enhancements

It is undoubtedly the case that this synchronisation process requires many more manual steps than is desirable.  However, it is still both easier and more reliable than re-entering all the information into Ancestry manually, and is the most viable option for linking ƒh with Ancestry tree hints that is available at the present time.

Significant improvement could be obtained if we could exploit the RootsMagic “Merge” process rather than the flawed “Compare”.  “Merge” uses an extended GEDCOM tag, _UID, to identify individuals unambiguously, and appears to be completely reliable.  Unfortunately, it is additive only, and simply combines records from different records, with no concept of which is the master copy for updating purposes.

RootsMagic generates and stores _UID fields automatically.  ƒh can store them, but simply as unclassified data.  It does not generate its own, or support using them for record identification.  However, if ƒh were to import and store the RootsMagic-generated _UID tags, this would greatly aid subsequent merging.  To do this effectively would need direct access to the RootsMagic database file, otherwise we are just replacing one manual process by another.

RootsMagic files are stored in SQLite, which is a well-supported and popular relational database management system.  This means that they can be read directly (and even written to) by other applications using the appropriate tools. One such tool is the LuaSQL library, which makes it possible to access the RootsMagic file directly from within ƒh via a suitable plugin.  While simple prototypes have been developed with FH6, this library is not (yet) available for FH7.  Until exploitation in the current version of ƒh becomes possible, it is difficult to justify the (considerable amount of) work required to implement and thoroughly debug.

Another potential complication is the upcoming release of RM8.  While indications from the publicly available December 2020 Community Preview are that the existing manual process will work in a very similar way in both RM7 and RM8, the detailed database structure is different (and incompatible) between the two versions, so any future plugin would need to take this into account.

Last update: 17 Jan 2021