Edgewall Software
Modify

Opened 18 years ago

Last modified 9 years ago

#2382 new enhancement

WebAdmin: resync from the web interface

Reported by: Manuzhai Owned by:
Priority: normal Milestone: next-major-releases
Component: version control Version: 0.9
Severity: normal Keywords: webadmin multirepos
Cc: manuzhai@… Branch:
Release Notes:
API Changes:
Internal Changes:

Description

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

Attachments (3)

admin-resync.diff (3.6 KB ) - added by Manuzhai 18 years ago.
Adds a Resynchronization module to WebAdmin.
2382.patch (5.2 KB ) - added by Carsten Klein <carsten.klein@…> 14 years ago.
Proposed patch for trac-0.12dev
2382.1.patch (6.1 KB ) - added by Carsten Klein <carsten.klein@…> 14 years ago.
Also includes the changes to trac.versioncontrol.cache

Download all attachments as: .zip

Change History (15)

by Manuzhai, 18 years ago

Attachment: admin-resync.diff added

Adds a Resynchronization module to WebAdmin.

comment:1 by markus, 18 years ago

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

comment:2 by Christopher Lenz, 18 years ago

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

comment:3 by Manuzhai, 18 years ago

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.

comment:4 by Christian Boos, 17 years ago

Component: generalversion control
Keywords: webadmin added
Milestone: 0.12
Owner: changed from Jonas Borgström to Christian Boos

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.

comment:5 by Christian Boos, 15 years ago

Keywords: multirepos added
Milestone: 0.130.12

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

comment:6 by Christian Boos, 15 years ago

Milestone: 0.122.0

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

by Carsten Klein <carsten.klein@…>, 14 years ago

Attachment: 2382.patch added

Proposed patch for trac-0.12dev

comment:7 by Carsten Klein <carsten.klein@…>, 14 years ago

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?

in reply to:  7 comment:8 by Carsten Klein <carsten.klein@…>, 14 years ago

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.

by Carsten Klein <carsten.klein@…>, 14 years ago

Attachment: 2382.1.patch added

Also includes the changes to trac.versioncontrol.cache

comment:9 by Carsten Klein <carsten.klein@…>, 14 years ago

Well it is sort of late ;)

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

Please consider 2382.1.patch:ticket:2382 instead.

comment:10 by Christian Boos, 14 years ago

Milestone: 2.0unscheduled

Milestone 2.0 deleted

comment:11 by Remy Blank, 14 years ago

Milestone: triagingnext-major-0.1X

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.

comment:12 by Ryan J Ollos, 9 years ago

Owner: Christian Boos removed

Modify Ticket

Change Properties
Set your email in Preferences
Action
as new The ticket will remain with no owner.
The ticket will be disowned.
as The resolution will be set. Next status will be 'closed'.
The owner will be changed from (none) to anonymous. Next status will be 'assigned'.

Add Comment


E-mail address and name can be saved in the Preferences .
 
Note: See TracTickets for help on using tickets.