2010/2/25 Bob McConnell <rmcconne@...>:
> Doug Blank wrote:
>> On Thu, Feb 25, 2010 at 1:20 PM, Bob McConnell <rmcconne@...> wrote:
>>> From your description of Gramps-connect, that is simply an export pipe to
>>> copy the data into a real database manager. That shouldn't have to be a
>>> copy, but should be where the application normally keeps all of its data.
>>> Requiring extra steps to import and export data will always cause problems,
>>> even without disguising that requirement occasionally (see first paragraph).
>> Do you want the data in tables or not? If you want to leave it in the
>> existing tables, then don't export it to gramps-connect. If you want
>> to work with your data in tables, then use gramps-connect? You can't
>> do both (not yet anyway).
> I don't want any application to store *my* data in a form and location
> where I have to use that application to access it. It should also be
> accessible from multiple machines simultaneously, even over a VPN. If we
> could do that, we wouldn't need to be passing these files around. I
> could give all of my correspondents remote access to one of my servers
> where we would maintain a single data set.
> I did figure out how to rename and export each tree. I then used `diff`
> to identify the differences between them. Apart from an amazing number
> of meaningless timestamps, there were actually very few differences. It
> looked like timestamps were being updated every time I viewed a record,
> whether it was changed or not.
Yes, I was going to suggest that: export to gedcom and do diff. But a
rename of all timestamps is needed, the new timestamp every time is a
bug that will be fixed in next version.
The workflow to do what you did in 2.2 in 3.x would be: import gedcom
in new family tree, update family tree (atomic writes to database, no
fear of data loss), export to gedcom when finished, remove family
tree. Then all will be identical as what happened in 2.2 without the
user being aware it happened like that.
Further, I want to point out that you are mistaken in the believe that
gramps 2.x is a direct Gedcom editor. In reality it imports gedcom in
a memory database as the one you see in 3.0 on disk, edits that, and
on exit writes out the gedcom again. So it is a bit of an illusion
that goes on.
Obviously this led to many problems on crashes as the inmem db does
not have atomic commits and also no roll back, causing 3.0 to remove
that option, and do an import in a real database instead.
Due to the fact that Gedcom is an unmaintained standard, there are at
the moment no real gedcom genealogy applications left, all have in one
way or the other extended Gedcom for their own needs
Gramps can fully export to the last revistion GEDCOM 5.5, but not all
data present in Gramps is present in the GEDCOM.
Hence, as a Gedcom editor, it is not really good, but then, as said,
all genea apps of 2010 will show this problem. Gedcom is only valid as
used by people to exchange information. Most genea apps have extended
Gedcom so the program itself can fully read it's own generated gedcom
(but other apps not). Gramps has decided to stick with the last
standard, and use it's own free, open, file format, the gramps xml,
for gramps to gramps data exchange.
Anyway, all these decisions seem reasonable and well thought through to me.
As to the problem of multiple imports in different family trees, that
is indeed how it is designed now. A warning when it happens would
indeed be a usability improvement, I opened a bug for it:
>>> Since what I really need is an editor for GED files, it is apparent that I
>>> should keep looking. I thought 2.0 was a good start in that direction, but
>>> that was on MythDora 4 (FC6). I'll have to see if I can find a copy of it
>>> for a more current distribution.
>> Gramps is not a GEDCOM editor. GEDCOM has many limitations.
> The theoretical limitations of GEDCOM are irrelevant, it has been
> completely adequate for our needs.
> One last question before I unsubscribe. Can I open two instances of
> Gramps simultaneously viewing different family trees? That would allow
> me to do a side by side comparison. I also need to compare the latest
> version with the copy on rootsweb, which I just downloaded. If those
> numbers in the lower right corner are head counts, there is a difference
> of 29 people between them.
> Thank you,
> Bob McConnell
> Download Intel® Parallel Studio Eval
> Try the new software tools for yourself. Speed compiling, find bugs
> proactively, and fine-tune applications for parallel performance.
> See why Intel Parallel Studio got high marks during beta.
> Gramps-users mailing list