2007/10/30, Douglas S. Blank <email@example.com>:
[Moving to developers list.]
The controversial aspect of this is the automatic merge (which is, of
course, the whole point). We can do this as a "fork" of the current GEDCOM
import, but that wouldn't be useful for anyone else, and would quickly
suffer "bitrot" as the original GEDCOM import continued to change. Perhaps
there is a way that we can work within the GRAMPS GEDCOM import?
Well, in 3.0 you could make an automatic revision, then work on a the data, and do rollback to revision if problems.
I always planned on working on a better (perhaps two-stage, interactive)
merge-er. But an easier option would be to have some type of option on the
Import Dialog that either: a) kept all duplicates, or b) attempted
automatic merges. This would be less controversial (I think) if there was
an "Undo Import" that was quick and painless, and readily available. Is
I see possibilities with automatic merge, but it should be on a unique identifier. I just have too many people with the same name to be able to have the name determine the merging or not (that is, all first sons of all children have the name of their grandfather, and are born in the same decade or so).
Would developers allow a GEDCOM import to do automatic merges in the same
manner that ImportCSV works?
I would rather see GEDCOM -> XML, and allow automatic merge of XML.
Like this the typical problem of importing GEDCOM is separated from the merging, we allow merging of gramps family trees without the need to pass over GEDCOM, and we have power over our XML format, so we can add things there, so we could make export to XML and have extra data written needed for possible merging.
Note that an overwrite in XML is already as easy as replacing the handle with the handle of an existing object.