Edgewall Software
Modify

Opened 12 years ago

Last modified 2 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@…
Release Notes:
API 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 12 years ago.
Adds a Resynchronization module to WebAdmin.
2382.patch (5.2 KB ) - added by Carsten Klein <carsten.klein@…> 7 years ago.
Proposed patch for trac-0.12dev
2382.1.patch (6.1 KB ) - added by Carsten Klein <carsten.klein@…> 7 years ago.
Also includes the changes to trac.versioncontrol.cache

Download all attachments as: .zip

Change History (15)

Changed 12 years ago by Manuzhai

Attachment: admin-resync.diff added

Adds a Resynchronization module to WebAdmin.

comment:1 Changed 12 years ago by markus

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

comment:2 Changed 12 years ago by Christopher Lenz

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 Changed 12 years ago by 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.

comment:4 Changed 10 years ago by Christian Boos

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 Changed 8 years ago by Christian Boos

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 Changed 8 years ago by Christian Boos

Milestone: 0.122.0

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

Changed 7 years ago by Carsten Klein <carsten.klein@…>

Attachment: 2382.patch added

Proposed patch for trac-0.12dev

comment:7 Changed 7 years ago by 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?

comment:8 in reply to:  7 Changed 7 years ago by 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.

Changed 7 years ago by Carsten Klein <carsten.klein@…>

Attachment: 2382.1.patch added

Also includes the changes to trac.versioncontrol.cache

comment:9 Changed 7 years ago by 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.

comment:10 Changed 7 years ago by Christian Boos

Milestone: 2.0unscheduled

Milestone 2.0 deleted

comment:11 Changed 7 years ago by Remy Blank

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 Changed 2 years ago by Ryan J Ollos

Owner: Christian Boos deleted

Modify Ticket

Change Properties
Set your email in Preferences
Action
as new The ticket will remain with no owner.
The ticket will be disowned. Next status will be 'new'.
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.