WebAdmin: resync from the web interface

[Manuzhai]

It would be nice to be able to resynchronize from the web interface. I've written a WebAdmin component that does this for any repository that supports the 'sync' method.

(Should we have a WebAdmin component for tickets?)

[Manuzhai]

Adds a Resynchronization module to WebAdmin.

[markus]

Looks good IMHO. But what I'm missing is an interval option, see #1271 for cboos' proposal.

[cmlenz]

Resync can potentially take quite a long time, so I'm not sure it's a good idea to do this from a request handler.

I'd also put this functionality on a Version Control page, that would in the future probably allow other types of operations (such as selecting the repository type and directory/URL).

[Manuzhai]

I like the idea of calling it Version Control.

About the request taking too long: do we have data on how long resync takes on very large repositories? What is the risk that the resync takes longer than the timeout?

I quite like the idea of interval resyncing, this would also make it not take so long. I'm thinking I would just do one field that says how many revisions to resync. Could default to say, 10 revisions. Possibly, we could impose an upper limit on the number of revisions that can be resynchronized from the web, so we're sure it doesn't take too long.

[cboos]

resync, and other version control operations like changing the scope of the repository (or adding/remove repositories, see #2086) should certainly deserve an admin module.

[cboos]

If resync is triggered from an admin panel, this should probably be done in some asynchronous way.

But anyway, beyond resync, there are other useful repository management tasks to do (related to #7822).

[cboos]

See also the discussion about triggering the sync from the WebAdmin interface that took place in #8291.

[Carsten Klein <carsten.klein@…>]

Proposed patch for trac-0.12dev

[Carsten Klein <carsten.klein@…>]

Here is a different approach that will utilize the current repositories admin panel.

However, this only works under local conditions and not in public trac environments or very large trac environments.

Perhaps introducing standard cron jobs or a daemon that would take over the responsibility for resynchronizing existing repositories would be more like it? With even shutting down browser access for the time being, while the repository cache is being resynchronized?

So, for example, a standard cron job could do for example a nightly resynch on all repositories, whereas an admin panel triggered resynchronization job would be executed by a separate daemon.

As for individual revision syncs, I think that this would best be integrated into the repository editor, since displaying revision information in the main panel would definitely be way too much information on the main page. Otherwise, make the revision information collapsible, and allow users to select individual revisions for resynch/sync.

About the patch 2382.patch:ticket:2382​: it will introduce (hopefully backwards compatible) changes to both the trac.versioncontrol.api.Repository.sync() method and also the trac.versioncontrol.admin module.

The changes include calls to the _sync() method of the IAdminCommandProvider interface and also providing feedback to the user once the resynchronization was done.

As for the localization/translation of introduced additional texts. I leave this up to you ;) - frankly I have not yet looked into the localization part so as to provide a working translation for the texts included with the patch.

Perhaps this can be used as a starter for getting things on their way?

[Carsten Klein <carsten.klein@…>]

Replying to Carsten Klein <carsten.klein@…>:

However, this only works under local conditions and not in public trac environments or very large trac environments.

Of course, this will work in all of the above depicted scenarios, but I do not know what implications there are when being used on a public site or with very large repositories.

[Carsten Klein <carsten.klein@…>]

Also includes the changes to trac.versioncontrol.cache

[Carsten Klein <carsten.klein@…>]

Well it is sort of late ;)

I forgot to include the changes to trac.versioncontrol.cache

Please consider 2382.1.patch:ticket:2382​ instead.

[cboos]

Milestone 2.0 deleted

[rblank]

In addition to a full resync being asynchronous, I believe a message should be shown on e.g. the browser and log pages while the operation is in progress, instead of showing the repository in an earlier state. A ranged resync should not display the message, as the cached data is already there, but being replaced progressively.