Adding global and per-repo settings to Kallithea

Thomas De Schampheleire patrickdepinguin at
Tue May 19 08:04:23 EDT 2015


I would like to get some clarification/discussion on adding new
settings to Kallithea, both global and per-repo settings.

For global settings, there is a 'settings' table that has one row per
setting, each setting having a name, value and type.
This is a nice and simple implementation.
However, it seems that when new settings have been added in the past,
there was always a database migration associated with it. This
migration is not that big of a deal, but still doesn't seem necessary
to me.
When a setting is not present in the database, the default should be
applied instead (at runtime, without changing the db). When a setting
is first changed, the database is updated with the right setting.
Alternatively, the setting is defaulted in the database when it is
first used and found to be missing from the database.

Does this make sense to you? Do you agree that a database migration is
not necessary?

Regarding per-repo settings: is this currently implemented in some
way? If so how? If not, how should we best implement this?
In the repositories table, there are several columns that could be
considered as per-repo setting, but it is not very nice to keep adding
columns for every new per-repo setting.
Such columns include landing_revision, enable_locking, ...

Thanks for the feedback,

More information about the kallithea-general mailing list