From: Gerald B. <ger...@gm...> - 2007-10-30 10:47:32
|
If the familysearch gedcoms have unique ids for people, events etc them gramps import could discard the duplicates as an option. So you could start a new db, import the geds (removing dups), the open your good db and import the new db into it. On 10/30/07, Benny Malengier <ben...@gm...> wrote: > 2007/10/30, Douglas S. Blank <db...@cs...>: > > > > [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 > > there? > > > 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. > > Benny > |