Opened 19 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: |
Attachments (3)
Change History (15)
by , 19 years ago
Attachment: | admin-resync.diff added |
---|
comment:1 by , 19 years ago
Looks good IMHO. But what I'm missing is an interval option, see #1271 for cboos' proposal.
comment:2 by , 19 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 , 19 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 , 18 years ago
Component: | general → version control |
---|---|
Keywords: | webadmin added |
Milestone: | → 0.12 |
Owner: | changed from | to
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 , 16 years ago
Keywords: | multirepos added |
---|---|
Milestone: | 0.13 → 0.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 , 15 years ago
Milestone: | 0.12 → 2.0 |
---|
follow-up: 8 comment:7 by , 15 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?
comment:8 by , 15 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 , 15 years ago
Attachment: | 2382.1.patch added |
---|
Also includes the changes to trac.versioncontrol.cache
comment:9 by , 15 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:11 by , 14 years ago
Milestone: | triaging → next-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 , 9 years ago
Owner: | removed |
---|
Adds a Resynchronization module to WebAdmin.