Menu
▾
▴
Re: [Gramps-devel] GEPS023 merge into trunk
|
From: Jérôme <rom...@ya...> - 2011-11-29 06:53:58
|
Hi, I was a little bit stucked by the new source/citation handling! For GeneWeb, I looked at libgedcom, but gedcom file format can fill some data on citation fields, GeneWeb cannot. Otherwise, export to GeneWeb ignore sources on person/family/events (3.2.x, 3.3.x), I kept this limitation for the citation support/migration. Sources import with this file format is full/complete! For this migration/support, Tim pointed out that method is modified: we do not set an object any more when we add a source, but add something like a relation with source.handle and commit it to the database. Maybe to add a pseudo set_source() somewhere into gen.lib, will make the code more 'direct'? Yes, it is indirectly related to set_citation_list(), but only gedcom file format provides data on citation (inherited by gedcom), ie. we need to generate an empty citation for adding source during import on some file formats. I guess this might be the same way on plugins (API, reports, tools, gramplets, views, simple access, etc ...) 'gen.lib.citation.py' is equivalent to current 'gen.lib.src.py' but maybe a quick access to something like this citation itself is maybe missing? Could be an enhancement for gen.lib: a way to fill citation_list with only one empty citation, then to fill/set previous source fields? Note, to merge some 'empty' citations, makes my data 'more compact'! ie. it is like cleaning all our empty sourceref (no data). This is great for users but also for our databases. :) Minor changes which could be also merged is maybe the focus set for some fields on Editors and minor improvements for accessibility (ATK objects, tooltips, shortcuts, etc ...), but very cosmetic on the 'merge into trunk' process. Thanks! Jérôme Tim Lyons a écrit : > On 28 Nov 2011, at 14:19, Brian Matherly wrote: > >> Tim, >> >> >>> I now believe that the GEPS023 branch is ready to merge into trunk, >>> and would ask that the core developers could test it and agree that >>> it is ready for the move. >>> >> As long as there are no crashes, then I agree we should merge the >> changes into trunk. I assume that the importers/exporters that are >> not updated yet don't crash - they just don't support citations. If >> we are crash free, then let's get the changes into trunk. If there >> are crashes, let's work them out before we merge. > > > > I presume that you are talking about the 'core' Gramps build. There > are some modules in the sourceforge trunk repository that do not > appear to be used in the current Gramps. With that proviso: > * Jerome has done GeneWeb, > * the parts of the simple report that are used in 'core' work, > * I can't update ImportProGen, because I don't have access to the > application for testing and anyway should it be regarded as part of > 'core'? > * It is possible that there are some other parts of the core Gramps > build that might fail because of citations. I have done the relevant > searches of the code, and run through most of the functions during > testing, but I cannot be sure that something else will not crop up. > Hence the need for more exposure in trunk. > > webapp/*, ExportFtre, ImportGrdb and the rest of the simple access > routines are either not used in the core, or not included in the core. > > > Import/Export CSV will probably fail (python exception). > > So, I believe that if I update the CSV modules, I will have met your > criteria, would that be agreeable? > > > >> If we are worried about the GEPS branch diverging from trunk, you >> can merge trunk changes into the GEPS branch. In fact, if you expect >> a lot of conflicts from the merge, I highly recommend that you first >> merge all trunk changes into the GEPS branch. Then, merging into >> trunk should have no conflicts. > > I have already done two merges of trunk into the GEPS branch (Rev > 18405 and 18498), and of course there were a few conflicts, which I > resolved. However, with things like reports etc being more volatile, > there is a chance that future merges are not so readily resolvable. > Hence I am keen to do the merge as soon as possible. > > >> Keep up the good work, > > Thanks. > > > > ------------------------------------------------------------------------------ > All the data continuously generated in your IT infrastructure > contains a definitive record of customers, application performance, > security threats, fraudulent activity, and more. Splunk takes this > data and makes sense of it. IT sense. And common sense. > http://p.sf.net/sfu/splunk-novd2d > _______________________________________________ > Gramps-devel mailing list > Gra...@li... > https://lists.sourceforge.net/lists/listinfo/gramps-devel > |