Hello, On Tue, 19 May 2015 14:04:23 +0200 Thomas De Schampheleire <[email protected]> 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
pgp4M2EQNxml8.pgp
Description: OpenPGP digital signature
_______________________________________________ kallithea-general mailing list [email protected] http://lists.sfconservancy.org/mailman/listinfo/kallithea-general
