0

In the company I am working, we're using a subversion (svn) repository to store our files and work together on "things".

Using shapefiles for now we're looking to go over to gpkgs because it's more efficient and there's only 1 file instead of 4-5 (shp,shx,prj,... etc.).

The problem we're having is that or subversion "system" doesn't seem to like gpkgs because it's always updating files that weren't even touched or changed which leaves to conflicts in committing files.

Does this appear to somebody else and what was the solution? I am not really an IT-guy but I can ask our department if there's any needed information.

Improve this question

2 Answers 2

Reset to default
2

Your comment about "updating [gpkg] files that have not been changed" leads me to suspect that, in your case, the problem is related to Why does simply opening a geopackage (gpkg) "modify" the file?, i.e. that gpkg files to which no actual edits were made are labelled as updated due to journalling. Then svn sees them as being changed and therefore re-updates them.

If this is the case, then:

  1. Make sure you are using QGIS version 3.26 or higher, since a change was made to the gpkg journalling mode in 1st half 2022 that stops this update if indeed no layers in the gpkg have been opened in edit mode, just in "read" mode. (There were some initial gremlins in this change, but I think the final fix was in https://github.com/qgis/QGIS/pull/48692, which made it into QGIS v 3.26.)

  2. Alternately, or in addition to be on the safe side, if you are sure the gpkgs will not actually get edits made to them, you could make them read-only at the operating system level (e.g. in Windows, set Attribute read-only in Properties in Explorer for the file).

The above is a solution in case you can segregate your layers into those that are actively being edited versus those that are (at least temporarily) read-only, and make sure the read-only ones are kept in different gpkgs from those that are being changed. If you are moving from shapefile (congrats!) and keeping individual layers as separate gpkg files, just as they were separate shp files before, this will naturally be true. However, you will soon discover that, apart from this versioning issue, gpkgs also have the ability to act as a container for multiple layers in one file. This is very powerful in general, but if you do edit but one feature in one layer in a gpkg, svn and similar SCS will need to store that whole gpkg. This is then a fundamental limitation, and the recommendation in Ian Turton's answer to use a more sophisticated RDMS is the best solution.

Improve this answer
1
  • thank you for the information on 1.). I see switching to gpkg may not be easy. But i also think that they're "better" :)
    – Johannes Keller
    Commented Mar 23, 2023 at 11:09
1

Source control systems (SCS) like subversion and git are designed to handle text files so they can save just the changes when the files are pushed to the server. For source code this is very efficient, as you have found out they are very poor at handling (large) binary files like GeoPackages or Shapefiles as one change means the entire file must be saved to the system.

If you need to share data between users the best (and really only good) solution is a shared, networked RDMS like Postgis.

Improve this answer
1
  • thank you, i will talk to my colleague about options to implement this in a way its useful to our workflow
    – Johannes Keller
    Commented Mar 23, 2023 at 11:09

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.