Edgewall Software
Modify

Opened 19 years ago

Closed 19 years ago

#3175 closed defect (duplicate)

No changeset xxx in the repository

Reported by: sven Owned by: Christian Boos
Priority: high Milestone:
Component: version control/browser Version: 0.9.4
Severity: major Keywords: no changeset repository
Cc: Branch:
Release Notes:
API Changes:
Internal Changes:

Description

running linux fedora core 5, apache 2.0.54, trac 0.9.4, subversion 1.2.3.-2.1 current subversion revision: 1400 database using for svn: FSFS

Subversion (is / seems to be) working just perfectly fine, When I do a checkout / update, I get the entire tree as I should. Yet when I try to access part of my repository tree with trac using browse source, I get this following error:

No changeset 360 in the repository

If I check the parent directory in TRAC (..), and change the revision I am viewing to 360, I dont get an error, it shows a revision tree, only the specific directory is missing. This is correct, since this directory used to be in a different location until revision 650 or so.

in bash, svn list .. -r360 (same as viewing the parent directory in trac) also does NOT show me the directory, which is correct.

svn list . -r360 in that specific directory returns content, showing me it to actually should exist.

now, is this a subversion error or trac error? Obviously, this directory didnt exist before, it was moved in place there aournd r650.. so if didnt exist in r360, right.. but why r360? svn log doesnt show any commit at all in that area of the tree on r360, and even so, trac will NOT show me the HEAD tree because r360 doesnt exist.. but it so does! In bash, an ls in the repos/db/revs directory also shows file 360 to be there, as it should.

I just started to use trac, and I really like it, but Im directly stuck at this one. any help please? Dunho if the severity and priority is set ok, but to me it is. TRAC is pretty much unusable to me if I cant browse source,

Attachments (0)

Change History (6)

comment:1 by anonymous, 19 years ago

Severity: majorblocker

comment:2 by anonymous, 19 years ago

Owner: changed from Jonas Borgström to Christian Boos

comment:3 by Christian Boos, 19 years ago

Severity: blockermajor

Well, I have some difficulties to follow what's going on here. First start by giving explicit paths instead of the generic '/', '.', '..'. Also, mention what's your repository location in the filesystem and what's the repository_dir you're using, so that I can see if it's a scoped repository or not (there are some issues with scoped repositories in 0.9, in particular #1830, which can exhibit the kind of error you're reporting; those issues have been fixed in trunk for 0.10).

And for the severity, we ideally would use blocker only if the issue is about an error that prevents any use of Trac in the general case.

comment:4 by anonymous, 19 years ago

Sorry for the blocker thing, I actually put it back to blocker since I thought it would be less severe then major. Figured it _blocked_ a certain functionality, which is the repository browser, since its practically useless at the moment..

first off, in subversion itself, all works ok. Only trac shows the problem

Then, the location of the repository in the filesystem is /svn/asca. (We have multiple repositories stored in /home/subversion but its always accessed through a symbolic link in root: /svn. The one with the problem is /svn/asca)

about the repository, so you understand the way we set it up: we have multiple projects with multiple programmers. All projecs are located in /svn/asca/projects. each project has a systems library directory 'slib' which is a branch, located in /svn/asca/projects/projectname/trunk/slib. The trunk for the system libraries is /svn/asca/libraries/slib/trunk. All programmers make changs to their version of slib to fix bugs, add new functionality, etc. From time to time, all these changes are merged back into the trunk, and from time to time, a new stable trunk version is merges back into the projects so that everybody has these new changes.

The trac installation that has a problem is using /svn/asca/projects/andrade as a base repository path (I guess that would be repository_dir), so its not using the root of the repository. When I look in trac in /trunk (assuming the / root dir is /svn/asca/projects/andrade!) in the HEAD revision, all looks ok. As soon as I enter the sub directory /trunk/slib, I get the error

No changeset 360 in the repository

/svn/asca/projects/andrade/trunk/slib did not yet exist until revision 600 or so. It did exist in the repository, but only in the trunk /svn/asca/libraries/slib/trunk (which is outside the scope of the repository_dir). At revision 600 (more or less), all projects received their own branch of the slib trunk.

I hope this is clear enough.. if any other help is needed let me know..

comment:5 by anonymous, 19 years ago

just checked ticked 1839, and yeah, this looks pretty much the same. Any idea on when will 0.10 be released?

comment:6 by Christian Boos, 19 years ago

Resolution: duplicate
Status: newclosed

Thanks for the clarifications. It's indeed a duplicate of #1830.

Concerning 0.10, I'd say you could already start to use it, as it's pretty much stabilized now. A beta should come in a few weeks, but several sites are using 0.10dev since some times already (e.g. TracHacks, this one).

At least, you should use 0.10dev for the /svn/asca/projects/andrade project, where you really need it.

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.