Manage repositories in DB instead of trac.ini

[Remy Blank]

The goal of this task is to move the definition of repositories in the multirepos branch from trac.ini to the database, more precisely the repository table.

This requires the following actions:

• Implement retrieval of repository information from the DB.
• Creation of trac-admin commands to manage repositories (add, remove, rename, alias).
• Creation of admin panels for repository management.

The patches provided here will apply on top of #7723.

[Christian Boos]

Just to clarify, when you say:

move the definition of repositories in the multirepos branch from trac.ini to the database

do you want to have all the repositories managed in the db, even the non cached ones?

What I was thinking was simply to have an additional IRepositoryProvider which would return the cached repositories. I think it can be convenient to keep the trac.ini [repositories] as it is for specifying non-cached repositories.

Ok, when I say additional IRepositoryProvider, as there's not really a specific component for the cache, the RepositoryManager would actually do this. So as I see it, the RepositoryManager.get_repositories would return the repositories specified in the trac.ini file (the non-cached ones, like the type hg and direct-svnfs) plus the ones defined in the db (type svn).

[Remy Blank]

Replying to cboos:

do you want to have all the repositories managed in the db, even the non cached ones?

That's what I meant, yes.

What I was thinking was simply to have an additional IRepositoryProvider which would return the cached repositories.

I didn't find a good reason why the cached repositories should be treated differently, but I may be missing something.

So as I see it, the RepositoryManager.get_repositories would return the repositories specified in the trac.ini file (the non-cached ones, like the type hg and direct-svnfs) plus the ones defined in the db (type svn).

I had intended to keep reading repositories from trac.ini [repositories] in addition to the DB, for backwards compatibility.

But why restrict repository management in the DB to cached repositories? Why not just allow adding any type of repository through trac-admin (and the web admin component)? I would find it convenient to be able to add or remove HG repositories directly in the admin module.

This may be a general consideration: I find it awkward to have related things spread between the DB and trac.ini. For example, having the enum values in the DB, but specifying the default value in trac.ini feels somehow wrong. So in this case, I didn't want to introduce such an artificial difference.

[Remy Blank]

Patch on top of #7723 that adds repository management commands to trac-admin

[Remy Blank]

The patch above applies on top of 7723-multirepos-cache-4-r7684.patch​ and adds a RepositoryProvider that reads its repositories from the repository table in the database, as well as the following trac-admin commands to manage them:

• repository add
• repository alias
• repository list
• repository remove
• repository rename

Feedback welcome.

[Christian Boos]

I'll try to check the patches this week-end but at first glance they look very good.

As for comment:2, I'm OK with what you said. The backward compatibility stuff is enough for me, as I like the flexibility of adding/commenting out repositories directly in the trac-admin. That is, until I'll feel comfortable to use the new trac-admin commands ;-) By the way, for replacing the "commenting out" part, i.e. the fact that it's sometimes needed or convenient to temporarily disable a repository, maybe we could add an online/offline flag to the model?

[Remy Blank]

Replying to cboos:

By the way, for replacing the "commenting out" part, i.e. the fact that it's sometimes needed or convenient to temporarily disable a repository, maybe we could add an online/offline flag to the model?

Why not? But we need to define the semantics clearly. For example, what happens when an offline repository is notified of a new changeset? Is the notification still propagated, or is it somehow queued? Does the offline repository disappear completely from the interface, or is it visible but marked offline? You'll need to help me there, because I don't have a use case for offline repositories myself.

[Remy Blank]

Updated patch to current head of multirepos branch.

[Remy Blank]

Updated patch to current head of multirepos branch.

[Remy Blank]

Updated patch to current head of multirepos branch.

[Christian Boos]

Last version of the patch applied in r7969.

Great job Remy!