Edgewall Software
Modify

Opened 12 years ago

Last modified 15 months ago

#10884 new defect

trac-admin repository resync fails with TypeError : int argument required

Reported by: michel.guillot@… Owned by:
Priority: normal Milestone: next-stable-1.6.x
Component: version control Version: 0.12.4
Severity: normal Keywords: patch
Cc: Branch:
Release Notes:
API Changes:
Internal Changes:

Description

If for any reason a post-commit hook fails to signal a changeset (rev) has been added in the repository, then the following trac-admin command should re-synchronize it:

trac-admin /path/to/projenv repository resync "" rev

but it fails with the following error:

TypeError: int argument required

How To Reproduce: make the hook not operational, eg comment out the line in the hook script calling trac-admin. Then create a new changeset in the repository, TRAC should not trace this new revision in the timeline (normal). Then try to resynchronize it with the trac-admin resync command.

System Information:

CentOS Linux 5.8 Trac 0.12.4 CustomFieldAdmin 0.2.2 FullBlog 0.1.1 Genshi 0.6 (without speedups) mod_python 3.2.8 Pygments 0.9 pysqlite 2.6.0 Python 2.4.3 (#1, Jun 18 2012, 08:55:31) [GCC 4.1.2 20080704 (Red Hat 4.1.2-52)] setuptools 0.6c11 SQLite 3.3.6 Subversion 1.7.6 (r1370777) jQuery: 1.4.4

By applying the given patch, the resync command is working again.

Attachments (1)

cache.py.patch (405 bytes ) - added by Michel GUILLOT <michel.guillot@…> 12 years ago.

Download all attachments as: .zip

Change History (9)

by Michel GUILLOT <michel.guillot@…>, 12 years ago

Attachment: cache.py.patch added

comment:1 by Christian Boos, 12 years ago

Wait a minute, are you really typing:

trac-admin /path/to/projenv repository resync "" rev

<rev> should be an actual revision, if resync is used that way.

repository resync <repos> [rev]

    Re-synchronize trac with repositories

    When [rev] is specified, only that revision is synchronized. Otherwise, the
    complete revision history is synchronized. Note that this operation can
    take a long time to complete. If synchronization gets interrupted, it can
    be resumed later using the `sync` command.

    <repos> must be the repository name, not the repository path. Use `list` to
    see a list of repository names and associated paths. To synchronize all
    repositories, specify "*" for <repos>. The default repository can be
    specified using "(default)".

But in your case, you should rather use sync:

repository sync <repos> [rev]

    Resume synchronization of repositories

    It works like `resync`, except that it doesn't clear the already
    synchronized changesets, so it's a better way to resume an interrupted
    `resync`.

    See `resync` help for detailed usage.

i.e.

trac-admin /path/to/projenv repository sync ""

comment:2 by Michel GUILLOT <michel.guillot@…>, 12 years ago

Here is the typical command line I use:

# trac-admin /srv/trac/E05058SB repository resync "" 5429

so in the ticket I used a generalized description.

Without the patch, the command you suggest (sync) fails with the same error:

# trac-admin /srv/trac/E05058SB repository sync "" 5429

produces the output: TypeError: int argument required

If you look more closely at the source code (cache.py / sync_changeset), it's rather easy to understand this error message:

the rev parameter that's passed to _insert_changeset() is a unicode string when it should be an int - _insert_changeset() fails at line 289 (cache.py) when calling db_rev(rev) from class SvnCachedRepository (svn_fs.py line 237):

def db_rev(self, rev):
   return '%010d' % rev

So you see an int is expected.

That's why the patch I attached uses the normalize_rev() function so as to convert the revision to an int.

When this type error is fixed, the revision and node_change tables are updated correctly, but the repository table still has not the lastest revision, therefore the remaining lines of the patch update the repository table and delete the metadata so it gets updated too.

I don't know the Trac modules enough to be sure this patch is optimum but for sure it does work when it is applied: the cache seems correctly updated because the changeset can then be displayed and the timeline shows the revision that was missing.

Last edited 11 years ago by Jun Omae (previous) (diff)

in reply to:  1 comment:3 by Michel GUILLOT <michel.guillot@…>, 12 years ago

Replying to cboos:

Wait a minute, are you really typing: […]

See my response in comment:2

Last edited 12 years ago by Christian Boos (previous) (diff)

comment:4 by Christian Boos, 12 years ago

Milestone: next-stable-1.0.x
Owner: set to Christian Boos

Yes, I saw it. We need to verify this.

comment:5 by Ryan J Ollos, 10 years ago

Owner: Christian Boos removed

comment:6 by Ryan J Ollos, 8 years ago

Milestone: next-stable-1.0.xnext-stable-1.2.x

Moved ticket assigned to next-stable-1.0.x since maintenance of 1.0.x is coming to a close. Please move the ticket back if it's critical to fix on 1.0.x.

comment:7 by Ryan J Ollos, 5 years ago

Milestone: next-stable-1.2.xnext-stable-1.4.x

comment:8 by Ryan J Ollos, 15 months ago

Milestone: next-stable-1.4.xnext-stable-1.6.x

Milestone renamed

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.