Adding global and per-repo settings to Kallithea

[Andrew Shadura]

Hello,

On Tue, 19 May 2015 14:04:23 +0200
Thomas De Schampheleire <patrickdepinguin at gmail.com> wrote:

> 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?

It does to me. Mads, what's your opinion?

> 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, ...

We (me and Mads) have discussed about this a lot during last week's
hackathon in Copenhagen. Here's an excerpt from our notes:

   * Per Repo settings
       * https://bitbucket.org/conservancy/kallithea/pull-request/39/allow-to-enable-or-disable-hooks-on-a-per/diff 
           * using an association table makes it easy to reuse … but perhaps complex to maintain?
           * simple db migration step, avoids duplicating whole db ...
       * requirements:
           * admin - repo defaults indicates existing per repo settings: private, stats, locking, downloads (boolean fields on repository in database)
           * hg settings & extensions per repo (instead of manual .hg/hgrc editing) … and there is probably a case for similar git settings
           * per repo hooks and hook parameters - also git
           * notify per repo (but that might just be a hook)
           * theming? (not really, but perhaps, one day …)
           * other global config?
           * some kind of fancy group inheritance … but not in first milestone
       * stored today
           * bools on repos
           * settings table - 99% really global (perhaps except stylify_metatags, dashboard_items, repository_fields)
           * ui table, 1:1 database representation of mercurial config, contains stuff we want to make per repo, not much else … except git coverage
       * easy solution
           * add a nullable repo field to the ui table
           * need a way to distinguish between VCS-specific stuff and our own; see what TortoiseHg does and do the same? Perhaps, use a [kallithea] section?

I'm not sure how legible it is, but there are some ideas there :)

-- 
Cheers,
  Andrew
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: OpenPGP digital signature
URL: <http://lists.sfconservancy.org/pipermail/kallithea-general/attachments/20150519/12c59af0/attachment.sig>