Hi Francois (and others), thank you for raising this. AFAIK none of the users we talk to uses this feature. However there is some interest to start using it. Me and Antonio planned to work a bit on this aspect in Q1 2019. But would be good to agree asap on either or not use of SVN/GIT. The current use case is mostly to facilitate an audit trail (information security). Which seems already met by the recent EEA improvements.
Some aspects to consider:
Pro SVN
- SVN is size-efficient in storing document versions, a database may grow considerable if each record has a full copy of the xml blob
- SVN can display which aspects changed between two versions
- GN currently does not have a compare versions/return to version UI, SVN does offer a UI to browse versions
- Github does have a SVN interface, so it should be relatively simple to synchronize also to github, some may like the aspect that the metadata is also retrievable (and editable?) via github (or we implement a similar wrapper for the git protocol)
- SVN can easily store a folder structure of text and binary files (thumbnails, pdf, gpkg) along with the metadata, the database would need to capture a mef to store this info in a versioned way.
Pro Database
- No synchronization needed between database (workflow events) and SVN versions (would it be an option to fully replace the workflow-table by SVN, for example by adding an additional properties file on each metadata folder)
- No external dependency/yet another technology
- SVN may be buggy due to low adoption
If SVN is selected, the following optimisations should be considered
- Allow to configure an external SVN repository
- Allow to configure versioning for all records (not activated on a per record level), then also hide the ‘activate versioning’ button.
- Consider not to activate internal SVN by default, so basic users don’t get bothered with conflicting SVN-id which makes geonetwork startup fail.
If database is selected, the following optimisations should be considered
- develop a UI to view the history of a record and option to open/copy a version from history
- to evaluate what we do with metadata attachments, will they be versioned?
On 14 Dec 2018, at 17:46, Francois Prunayre <fx.prunayre@anonymised.com> wrote:
Dear all, quick question : is anyone using Subversion repository in
GeoNetwork ?
It looks like on some setup (when using NFS), the subversion repository
cause issue starting the application. Also the SVN interface is not really
available in version 3.x so 2 options identified to solve the NFS issue:
1) Removing SVN support
2) Make it optional (during the build with a profile or by settings)
In case of 1), it could be replaced on the long run first by adding record
history feature (see https://github.com/geonetwork/core-geonetwork/pull/3209)
which could be later improved by plugging a more recent version control
system like git.
Any thoughts ?
Thanks
Francois
_______________________________________________
GeoNetwork-users mailing list
GeoNetwork-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geonetwork-users
GeoNetwork OpenSource is maintained at http://sourceforge.net/projects/geonetwork