#9130 closed defect (worksforme)
"trac-admin env resync" terminates prematurely
| Reported by: | exarkun | Owned by: | |
|---|---|---|---|
| Priority: | normal | Milestone: | |
| Component: | general | Version: | |
| Severity: | normal | Keywords: | |
| Cc: | Branch: | ||
| Release Notes: | |||
| API Changes: | |||
| Internal Changes: | |||
Description
The path to my svn repository changed, so I ran resync as directed by the error in the web ui. However, the command completed claiming to be "Done." before it had actually sync'd all of the revisions. Partial transcript below:
trac-migration@cube:~/Run/trac/trac-projects/twisted$ trac-admin . resync Resyncing repository history... 7 revisions cached. Done. trac-migration@cube:~/Run/trac/trac-projects/twisted$ trac-admin . resync Resyncing repository history... 7 revisions cached. Done. trac-migration@cube:~/Run/trac/trac-projects/twisted$ trac-admin . resync Resyncing repository history... 9 revisions cached. Done. trac-migration@cube:~/Run/trac/trac-projects/twisted$ trac-admin . resync Resyncing repository history... 9 revisions cached. Done. trac-migration@cube:~/Run/trac/trac-projects/twisted$ trac-admin . resync Resyncing repository history... 9 revisions cached. Done. trac-migration@cube:~/Run/trac/trac-projects/twisted$ trac-admin . resync Resyncing repository history... 803 revisions cached. Done. trac-migration@cube:~/Run/trac/trac-projects/twisted$ trac-admin . resync Resyncing repository history... 12 revisions cached. Done. trac-migration@cube:~/Run/trac/trac-projects/twisted$ trac-admin . resync Resyncing repository history... [17717]
There are 28710 revisions in the repository. Using 0.11.6 on Linux, Python 2.5, postgresql backend.
Attachments (0)
Change History (3)
follow-up: 2 comment:1 by , 15 years ago
comment:2 by , 15 years ago
| Resolution: | → worksforme |
|---|---|
| Status: | new → closed |
Replying to rblank:
I wonder if resyncs due to normal requests could interrupt a running resync.
Yes they can. However, such a request should normally complete the sync, unless killed by the web front-end if it takes too much time. The next request should then continue with the sync, etc. Of course, if you do a resync meanwhile on the command line this would reset the tables and start the sync from 0 again.
As we don't have a trac-admin sync in 0.11.x like we have now in 0.12dev which simply completes a sync without resetting the tables, the best advice here is to put the web front end temporarily off line while the resync is in progress.
Anything special in the log? Did you shut down the web server during the resync, or did you get requests in parallel? I wonder if resyncs due to normal requests could interrupt a running resync.