#11238 closed defect (duplicate)
Trac crashes when trying to Blame ASCII file with subversion-1.7.5
Reported by: | Owned by: | ||
---|---|---|---|
Priority: | normal | Milestone: | |
Component: | general | Version: | 1.0 |
Severity: | normal | Keywords: | svn_uri_is_canonical, blame, crash |
Cc: | Branch: | ||
Release Notes: | |||
API Changes: | |||
Internal Changes: |
Description
If using Subversion 1.7.5 and viewing a content in blame mode for an ascii file Trac crashes by assertion svn_uri_is_canonical
.
Blame works fine with other subversion clients (AnkhSVN/TortoiseSVN/etc.) so it appears there's something wrong with the way Trac is creating the request.
trac.log
Trac[browser] DEBUG: Rendering preview of node build-release.bat@None with mime-type application/x-dos-batch; charset=utf-8 Trac[api] DEBUG: Trying to render HTML preview using PygmentsRenderer [blame, lineno] Trac[svn_fs] INFO: opening ra_local session to 'file:///opt/subversion/repository/[redacted]/trunk/Scripts/build-release.bat'
apache.log
apache2: /build/buildd/subversion-1.7.5/subversion/libsvn_subr/dirent_uri.c:1519: uri_skip_ancestor: Assertion `svn_uri_is_canonical(child_uri, ((void *)0))' failed.
Ticket #11167 references the same svn_uri_is_canonical
error when using subversion 1.7.x and trac 0.12-stable.
Attachments (0)
Change History (6)
follow-up: 2 comment:1 by , 11 years ago
comment:2 by , 11 years ago
Replying to cboos:
So how is this issue different than #11167? The latter has been fixed, but no released version of Trac 1.0 contains it yet (will be 1.0.2). So the crucial information missing here is, which revision of branches/1.0-stable are you using? It must be at least r11790 in order to contain the fix for #11167.
Thanks for the quick reply.
I figured there may indeed be a fix in the pipeline but because my filenames are ascii only I chose to take out a new ticket (in case the previous fix was for a slightly different issue).
I'm using Trac installed with easy_install, version 1.0. I'm not sure how to find the revision number of the installed code base though.
comment:3 by , 11 years ago
Version: | 1.0-stable → 1.0 |
---|
Ok, it's 1.0 then, so you don't have that fix yet. Please try to either apply that patch manually or (easier) to install from svn (see TracDownload#Tracstable for guidance). If it then works, you can close this as a duplicate.
comment:4 by , 11 years ago
Severity: | blocker → normal |
---|
Ok I'll give it a shot and let you know.
Last question; what is the recommended installation method for Trac in a production environment?
follow-up: 6 comment:5 by , 11 years ago
Resolution: | → duplicate |
---|---|
Status: | new → closed |
I've installed 1.0-stable from source and everything looks good so I'm closing this ticket as a duplicate. Thanks again for your help.
I'm still a little unsure about the version numbers used for Trac releases though. I noticed after building 1.0-stable that the version displayed is 1.0.2dev-r0. What's considered stable/development? I was under the impression that 1.0-stable would be stable, not dev and the wiki isn't too clear. Could you please clarify the releases when you have a chance?
comment:6 by , 11 years ago
Replying to rwb <rwb@…>:
[…] the version displayed is 1.0.2dev-r0. What's considered stable/development?
Well, the dev here indicates the in-progress status of the code on the stable branch. When it's time to do the actual release, we remove the dev label. The dev-r… part is supposed to indicate the revision number, but that's broken for Subversion ≥ 1.7.
A less equivocal label could be pre instead of dev.
So how is this issue different than #11167? The latter has been fixed, but no released version of Trac 1.0 contains it yet (will be 1.0.2). So the crucial information missing here is, which revision of branches/1.0-stable are you using? It must be at least r11790 in order to contain the fix for #11167.