Subversion ?

classic Classic list List threaded Threaded
5 messages Options
Reply | Threaded
Open this post in threaded view
|

Subversion ?

Francois Prunayre
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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/geonetwork-users
GeoNetwork OpenSource is maintained at http://sourceforge.net/projects/geonetwork
Reply | Threaded
Open this post in threaded view
|

Re: Subversion ?

Jose Garcia
Hi Francois

I don't think is really used by many people. I would vote for option 2 for
now if that is simple to add and then we have time to discuss what do with
that feature, probably replacing with git and adding also some feature  to
be able to view the change history would be really helpful.

Regards,
Jose García


On Fri, Dec 14, 2018 at 5:46 PM Francois Prunayre <[hidden email]>
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
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/geonetwork-users
> GeoNetwork OpenSource is maintained at
> http://sourceforge.net/projects/geonetwork
>


--













*Vriendelijke groeten / Kind regards,Jose García
<http://www.geocat.net/>Veenderweg 136721 WD BennekomThe NetherlandsT: +31
(0)318 416664 <+31318416664> <https://www.facebook.com/geocatbv>
<https://twitter.com/geocat_bv>
<https://plus.google.com/u/1/+GeocatNetbv/posts>Please consider the
environment before printing this email.*

_______________________________________________
GeoNetwork-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/geonetwork-users
GeoNetwork OpenSource is maintained at http://sourceforge.net/projects/geonetwork
Reply | Threaded
Open this post in threaded view
|

Re: Subversion ?

Francois Prunayre
Hi Jose,

Le lun. 17 déc. 2018 à 09:34, Jose Garcia <[hidden email]> a écrit :

> Hi Francois
>
> I don't think is really used by many people. I would vote for option 2 for
> now
>

Pull request is here https://github.com/geonetwork/core-geonetwork/pull/3372

Francois

if that is simple to add and then we have time to discuss what do with that
> feature, probably replacing with git and adding also some feature  to be
> able to view the change history would be really helpful.
>

> Regards,
> Jose García
>
>
> On Fri, Dec 14, 2018 at 5:46 PM Francois Prunayre <[hidden email]>
> 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
>> [hidden email]
>> https://lists.sourceforge.net/lists/listinfo/geonetwork-users
>> GeoNetwork OpenSource is maintained at
>> http://sourceforge.net/projects/geonetwork
>>
>
>
> --
>
>
>
>
>
>
>
>
>
>
>
>
>
> *Vriendelijke groeten / Kind regards,Jose García
> <http://www.geocat.net/>Veenderweg 136721 WD BennekomThe NetherlandsT: +31
> (0)318 416664 <+31318416664> <https://www.facebook.com/geocatbv>
> <https://twitter.com/geocat_bv>
> <https://plus.google.com/u/1/+GeocatNetbv/posts>Please consider the
> environment before printing this email.*
>

_______________________________________________
GeoNetwork-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/geonetwork-users
GeoNetwork OpenSource is maintained at http://sourceforge.net/projects/geonetwork
Reply | Threaded
Open this post in threaded view
|

Re: Subversion ?

Paul van Genuchten
In reply to this post by Francois Prunayre
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 <[hidden email]> 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
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/geonetwork-users
> GeoNetwork OpenSource is maintained at http://sourceforge.net/projects/geonetwork



_______________________________________________
GeoNetwork-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/geonetwork-users
GeoNetwork OpenSource is maintained at http://sourceforge.net/projects/geonetwork
Reply | Threaded
Open this post in threaded view
|

Re: Subversion ?

Francois Prunayre
Hi Paul, I agree with your comments. Now that we have a
GenericMetadataEventListener we can probably quite easily switch from DB to
a repo (git/svn) with what has been done recently on the record history
work (Antonio could confirm ?). Now the challenge is indeed to be able to
work with the history eg. revert an event, visualize changes, version more
details like attachments. We also have to check that we are able to do
proper search in the history - but probably both options will work well for
that.

Cheers.

Francois


Le ven. 21 déc. 2018 à 12:30, Paul van Genuchten <
[hidden email]> a écrit :

> 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 <[hidden email]>
> 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
> > [hidden email]
> > https://lists.sourceforge.net/lists/listinfo/geonetwork-users
> > GeoNetwork OpenSource is maintained at
> http://sourceforge.net/projects/geonetwork
>
>

_______________________________________________
GeoNetwork-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/geonetwork-users
GeoNetwork OpenSource is maintained at http://sourceforge.net/projects/geonetwork