RCS-based archives

When GRAMPS detects utility rcs is installed on the running computer, a new button Archive/Extract is available in the Manage Trees dialog. This button allows to create an XML “snapshot” of the current DB or to create a new database from a previous XML archive.

I have not yet fully analysed how the feature works, i.e. if the snapshots are always taken relative to the current state of the DB or relative to the latest snapshot to make profit of the “diff” capability of rcs and possibily minimise the size of successive snapshots.

Since rcs is somehow obsolete and no longer actively maintained if any (for source project management it has been superseded by more “modern” tools like git, svn, Hg, …), my question is about its present usefulness.

As far as you know, is the feature really used?

It is always possible to Backup instead which also produces an XML file. The only advantage with rcs would be saving only a “delta” over the latest backup but I doubt this is done or possible: this requires that the archives have a logical tree-like relationship among themselves. I suspect this is not the case and anyway when a previous snapshot is extracted, it creates a new independent DB of which future snapshots are not related to the original ones, thus cancelling the potential advantage of “delta-archiving” because new archives are hosted in a new archival tree (which therefore never takes the shape of a tree; it is rather a “comb”).

In this condition, is it opportune to consider dropping the rcs feature? Or else to redefine it under a strict, consistent specification?

Yes before a big edit or change, like a checkpoint you can roll back to quickly.

Semi-related conversation on reddit: Looking for workflow/toolset for storing GrampsXML in online git with an interesting idea by one of the commenters to replace RCS with Git for Gramps builtin Archive a family tree feature. I’d suggest converting the existing version control system (RCS or Git or any other) to addons that provide that functionality via a preference in settings the same as how you can select diffferent database backends in Gramps ?

Related Gramps feature request: 0004901: Add a new storage format base on GIT which has an interesting link to another persons method of using Gramps XML with Git

I see you last discussed this on the mailing list also a while ago Re: [Gramps-devel] Revision control feature? From: Patrick Gerlier 2020-03-25 17:57:33

I’d hazard no as it works on Linux and bothers no one on Windows , not sure about MacOs?

My workflow is a bit different. I don’t use Archive but Family Trees>Export which also gives an XML “snapshot”. The difference lies in the way you “comment” the export/archive. With Archive, your comment is shown in the Manage Trees dialog while in the Export case you must give a relevant file name. Basically, the result is the same. User-friendliness should be compared and rated.

As I mentioned, I doubt there is a substantial footprint advantage (total size of archives) because the archives are not linked in a parent-child relationship. I fear there are just siblings to the current DB and rcs doesn’t apply delta processing in this case.

Thanks for pointed me to this request. The comments rightfully points out the difficulty: BD XML description is “monolithic” presently, making difficult to take benefit of Git diff efficiently. In addition, we should check if records are always issued in same order. For instance, in the GNU suite for message translation (msgxxx and gettext), a small change in source strings may cause the *.po(t) files to undergo a dramatic change in the order of the various strings making diff comparison absolutely useless to have an idea about what changed. This means that any archival in an SCM (source code management) system will not use delta-backup at its best: practically the new complete string file is saved.

Before embarking into a tentative implementation, one must make sure that record issuance order is stable under any edits, including Gramps-id (hopefully, records are identified internally by their “handle” which never change over the life of a DB, but this “handle” is not the same from DB to DB: it changes when you Extract or Import).