Edgewall Software
Modify

Opened 20 years ago

Closed 18 years ago

Last modified 9 years ago

#1271 closed enhancement (duplicate)

[patch] Resync handles changeset intervals

Reported by: Christian Boos Owned by: Christian Boos
Priority: normal Milestone:
Component: admin/console Version: devel
Severity: normal Keywords: resync
Cc: vyt@… Branch:
Release Notes:
API Changes:
Internal Changes:

Description

This was suggested by Juanma Barranquero on the Trac mailing list Message 2162

This feature is useful for fixing formatting errors in one changeset, without having to resync the whole repository.

This is useful while waiting for #781.

Some explanations:

  • resync 1000
    will resync the repository starting at revision 1000
  • resync 1000:1010
    will resync the repository starting at revision 1000 ending at revision 1010
  • resync :1010
    will resync the repository starting at revision 1 ending at revision 1010
  • resync
    will resync the whole repository, as usual

Attachments (5)

resync_on_ranges--1333.diff (4.5 KB ) - added by cboos@… 20 years ago.
patch that implements the proposed feature
resync_on_ranges--1387.diff (3.9 KB ) - added by Juanma Barranquero 20 years ago.
Patch adapted to changes in [1379].
cache.py (6.2 KB ) - added by Manuzhai 19 years ago.
New patch to do the main work for this in a different place.
limited-sync.diff (2.9 KB ) - added by Manuzhai 19 years ago.
Sorry, wrong file. Here's the diff.
trac-0.9stable-r2652.resync-ranges.patch (5.8 KB ) - added by vyt@… 19 years ago.
Patch against 0.9 stable

Download all attachments as: .zip

Change History (31)

by cboos@…, 20 years ago

Attachment: resync_on_ranges--1333.diff added

patch that implements the proposed feature

by Juanma Barranquero, 20 years ago

Attachment: resync_on_ranges--1387.diff added

Patch adapted to changes in [1379].

comment:1 by Juanma Barranquero, 20 years ago

I've adapted this very useful patch to change [1379] on trunk.

BTW, it'd be really nice if this was accepted. Even if someday there is an interface to modify svn:log messages from Trac, resync'ing can be necessary, and this patch makes it much more bearable for large repositories, with just a little bookkeeping on the user's part.

comment:2 by cboos@…, 20 years ago

Owner: changed from daniel to anonymous
Status: newassigned

If Christopher is ok, I'll apply that patch.

I'll also have a try to adapt it to the new versioncontrol API.

comment:3 by Christopher Lenz <cmlenz@…>, 20 years ago

Sure, go ahead.

Note that the version control stuff is on my branch, so you'd have to provide a patch at this point.

comment:4 by anonymous, 20 years ago

The patch is non-valid again, after [1413].

comment:5 by mgood <trac matt-good net>, 20 years ago

Owner: changed from anonymous to Christian Boos
Status: assignednew

Oops, cboos, log in before you accept a ticket.

comment:6 by Manuzhai, 19 years ago

I would like to get this feature in soon so I can get on with #2382.

I've worked on a new patch which adds to parameters to the cached repository's .sync() method. It then becomes .sync(self, first = None, last = None).

Now, I've tried to run the existing tests on this patch, but that's not working so well. Three of the tests throw an Exception because the new code uses self.repos.rev_older_than(), which doesn't seem to exist on the mock repository. Not sure why this is, though.

Also, I'm afraid this patch in its current state is incompatible with PostgreSQL, because it seems to lack the INSERT OR REPLACE syntax. This could be implemented in rules for the PostgreSQL database, but I'm not sure that would work. Alternatively, the Python code could be expanded to switch on existence of the changeset metadata, but I think that would require an extra rev_older_than() for every changeset, making it slower still.

Any ideas on how we could clean this up?

(BTW: I was hoping this would go into trunk instead of vc-refactoring, since it seems fairly independent of what's going on in there.)

by Manuzhai, 19 years ago

Attachment: cache.py added

New patch to do the main work for this in a different place.

by Manuzhai, 19 years ago

Attachment: limited-sync.diff added

Sorry, wrong file. Here's the diff.

comment:7 by vyt@…, 19 years ago

Cc: vyt@… added

I try limited-sync.diff with trac 0.9, but trac-admin still resync whole repository. Please, tell me, where is complete patch for trac 0.9 ?

comment:8 by Christian Boos, 19 years ago

Milestone: 1.0

No one updated this patch for 0.9, AFAIK.

As part of the vc-refactoring, I'll try to adapt the resync support, so that it will be possible to implement #2482, #2382 and this one.

comment:9 by Christopher Lenz, 19 years ago

cboos, what does this enhancement request have to do with the vc-refactoring branch?

I'd really prefer that we keep the branch focussed on enabling pluggable VC system support.

comment:10 by Christian Boos, 19 years ago

The pending changes I have on the vc-refactoring branch are about a refactoring of the repository cache.

Hm, maybe that could be done as a refactoring step 2, as it's unfinished and will take some time to finalize.

Let's first merge the step 1, pluggable VC system support.

I'll sync the branch and temporarily remove a few things (tag support and such), in order to reach quickly a merge candidate.

by vyt@…, 19 years ago

Patch against 0.9 stable

comment:11 by vyt@…, 19 years ago

Attached patch is against 0.9 stable, works for me. Note that syntax

trac-admin project resync 3:

doesn't work but

trac-admin project resync 3:-1

works fine.

comment:12 by vyt@…, 19 years ago

About attached limited-sync.diff - it's cool but contain small error in line 84: condition should be "and not" instead of "or". Otherwise resync doesn't stop at specified last.

while current_rev is not None and not self.repos.rev_older_than(last, current_rev):

comment:13 by Christian Boos, 19 years ago

I'll try to integrate this once the vc-refactoring branch is merged … which should be imminent, now.

Vitaly, would you mind testing the branch and give some feedback?

comment:14 by vyt@…, 19 years ago

I do checkout as described in TracMercurial and everything seems to be ok. I test it on my test box, and old environment (created with 0.9 release) works fine. SVN renames, changes and deletion shown in Trac correctly. trac-admin project resync also works fine.

What I should test especially ?

comment:15 by markus, 19 years ago

Ok, the vc-refactoring branch has been merged into trunk some time ago. What about integrating this patch into current (0.10dev) trunk? The ticket is scheduled for 1.0… :(

comment:16 by Christian Boos, 19 years ago

Milestone: 1.00.10

I have a few things to finish before restarting the vc-refactoring but that feature will then be part of it.

comment:17 by Christian Boos, 19 years ago

Milestone: 0.100.11

Post-poning.

comment:18 by markus, 18 years ago

Just curious: If the VcRefactoring gets postponed to, say, 1.0, does this ticket have to wait then as well?

comment:19 by Christian Boos, 18 years ago

I did some small progresses this W.E. on the VcRefactoring front (the new cache). The goal is to have TracBrowser and TracChangeset operate mainly (if not exclusively) on the cache. So the resync will really become a critical and central operation. I'm not even sure at this point if partial resync would still work, as in some possible implementations, the cached node data will depend on what was there in the previous revision… so if you rebuild only [m:n], then n+1 might become non-sense…

If the partial resync wanted here is mainly for getting back the updated commit messages, I think a dedicated command will likely be more appropriate than the "complete" resync (something like changeset message [from:[to]]). If the resync is needed because the repository was rebuilt to omit a few last erroneous commits (i.e. the "obliterate" thing), then a truncate n operation could be done, and the automatic sync check will do the incremental resync from n

OTOH, while waiting for the above vaporware to condensate, if someone wants to refresh the above patch for 0.10.1, he would be welcome ;)

comment:20 by markus, 18 years ago

Thanks for the information. I finally read your VcRefactoring proposal as well and it seems like #781 does no longer depend on this ticket then.

I don't think we need an update of the patch above if we're going to split the resync command in two (or more) separate commands.

in reply to:  20 ; comment:21 by Christian Boos, 18 years ago

Replying to markus:

Thanks for the information. I finally read your VcRefactoring proposal … I don't think we need an update of the patch above if we're going to split the resync command in two (or more) separate commands.

Well, most of this is at the brainstorming stage ;)

Concerning #781, it's more dependant on changes happening at how the resources in general (a chanhgeset in this case) are stored. I hope to find time to write down a TracDev/Proposals/DataModel one of these days, as I think I finally found a plausible way to implement the TracObjectModelProposal.

in reply to:  21 comment:22 by markus, 18 years ago

Replying to cboos:

I hope to find time to write down a TracDev/Proposals/DataModel one of these days, as I think I finally found a plausible way to implement the TracObjectModelProposal.

Great, I'm looking forward to this one. As I have some spare time the next weeks I planned to create a plugin for #781, but wanted to have this ticket and #2348 "fixed" before I begin. Now that you'll come up with a new proposal (which sounds great) it seems like I have to wait a few more weeks/months before I can start with the plugin. :-(

Anyway, enough off-topic. We should switch to #781, I guess.

comment:23 by Christian Boos, 18 years ago

Milestone: 0.110.12

Will be part of the version control admin panel in 0.12.

comment:24 by Christian Boos, 18 years ago

Milestone: 0.12
Resolution: wontfix
Status: newclosed

Well, there's already #4797 and #2382 for this. Resyncing a range doesn't sound that useful anyway.

comment:25 by Christian Boos, 14 years ago

Resolution: wontfixduplicate

See #9979.

comment:26 by Ryan J Ollos, 9 years ago

Reporter: changed from cboos@… to Christian Boos

Modify Ticket

Change Properties
Set your email in Preferences
Action
as closed The owner will remain Christian Boos.
The resolution will be deleted. Next status will be 'reopened'.
to The owner will be changed from Christian Boos to the specified user.

Add Comment


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